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1.0  Introduction 

This  plan  establishes  the  Configuration  Management  (CM)  practices  and  procedures  to  be  followed 
in  support  of  the  Advanced  Distributed  Simulation  &  Training  (ADST)  contract  by  Loral  Western 
Development  Labs  (WDL).  The  plan  describes  the  CM  practices  and  procedures  required  for  the 
concurrent,  multi-site  development  and  support  of  the  ADST  BDS-D  (Battlefield  Distributed 
Simulation-Development)  programs.  This  plan  addresses  the  Software  Development  Fac^ty  in 
San  Jose,  Orlando,  subcontractors  working  on  ADST  Delivery  Orders  (DO's),  Ft  Knox  and  Ft 
Rucker. 

A  contractor  managed.  Configuration  Control  Board  (CCB)  will  be  established  at  the  Loral  WDL, 
San  Jose  facility,  which  will  monitor,  api»ove,  and  control  changes  to  the  common  ADST  product 
baseline.  Tlie  centralized  CCB  will  be  responsibte  for  adjudicating  baseline  changes  proposed  by 
the  various  development,  operational,  and  integration  functions.  This  plan  describes  the 
configuration  change  control  procedures  to  be  followed  by  the  CCB  and  identifies  the  relationship 
to  alternate  development  and  integration  sites  (i.e.,  Orlando,  Ft  Knox  and.  Ft.  Rucker)  and 
subcontractors  worl^g  on  ADST  Delivery  Orders  (DOs). 

Each  Delivery  Order  (DO)  organization  will  apply  standard  practices  and  processes  to  its 
design/development  and  integration  activity.  Systems  Engineering  will  be  responsible  for  the 
initiation,  development  and  coordination  of  all  DO’s  on  the  ADST  program.  CM  will  work 
closely  with  software  and  systems  engineering  u>  assure  consistency,  and  integrity  of  the  initial 
submissions,  procedural  changes  and  traceability  of  software  and  hardware  components.  Systems 
Engineering,  along  with  the  Program  Engineering  Manager  will  be  a  liaison  with  the  CCB  and  will 
coordinate  with  software  engineering,  integration  and  CM  on  software  deliveries.  In  order  to 
ensure  consistency  between  sites  and  DO’s,  and  adherence  to  the  policy  and  procedures  set  forth  in 
this  plan,  CM  operations  are  coordinated  with  the  BDS-D  Manager,  Site  coordinators,  and  the 
Loral  WDL  Program  Office. 

A  key  component  of  the  plan  will  be  the  identification  and  establishment  of  the  common  ADST 
software  baseline  as  a  reusable  system  component  as  well  as  identif^g  site  unique  differences. 
The  control  mechanisms  described  in  this  plan  serve  as  the  foundation  of  a  taUorable  standard 
applied  to  all  ADST  BDS-D  Delivery  Order  (DO)  efforts  in  addition  to  ongoing  baseline 
maintenance. 

The  LORAL  CM  system  described  in  this  plan  is  based  upon  and  complies  with  DI-CMAN-80858, 
MIL-STD- 1456A  as  tailored  to  the  ADST  program.  Although  the  ^ST  program  is  not  a  MIL- 
STD  project,  MIL-STD- 1465 A  definitions  and  terminology  are  used  throughout  this  document 


1.1  Description  of  the  SIMNET  Configuration  Item  (Cl) 

ADST  is  a  dirwt  descendent  of  the  DARPA/Aimy  SIMNET  program.  SIMNET  represented  a 
major  ^vance  in  the  Armed  Forces  ability  to  generate  selective  fidelity  representations  of  the  teal 
world  in  low-cost  simulators  for  combined  forces  training  and  system  evaluation.  However,  a 
milestone  has  now  been  reached.  The  proof-of-concept  program  is  complete  and  the  SIMNCT 
program  is  advancing  into  a  new  phase.  ADST  will  continue  research  and  development  of 
additional  simulators  and  functional  capabilities,  but  this  research  must  be  directed  by  user 
developed  requirements.  Advancements  will  be  phased  into  the  laboratory  testing  environment 
through  procedures  that  also  support  other  on-going  test  and  evaluation  processes. 
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The  Mission  of  ADST  includes  the  test  and  evaluation  of  conceptual  combat  systems;  training 
effectiveness;  organizadon,  tacdcs,  and  doctrine;  and  simulation  network  elements. 

The  mission  objectives  of  the  ADST  contract  are  stated  below: 

•  BDS-D  will  be  a  key  research  tool  for  faster  and  more  successful  development  of 
wei^ns  and  command  and  control  systems. 

•  BDS-D  will  be  used  in  evaluations  to  define  the  specific  training  tasks  and  methods 
of  assessment  for  simulator  training. 

•  BDS-D  provides  an  opportunity  to  view  and  evaluate  the  effects  of  changes  in 
organization,  tactics,  or  doctrine  in  realistic  combat  situations. 

•  BDS-D  will  be  used  to  support  developmental  testing  and  validation  to  expand  the 
simulation  netwoik  itself. 

Configuration  management  is  the  cornerstone  of  a  disciplined  process.  Existing  simulation 
network  elements  must  be  functionally  documented  and  placed  under  the  configuration 
management  process.  Most  critically,  supplemental  documentation  must  be  prepared  for  fiimctional 
and  performance  baselines  of  existing  ^uipment,  so  that  test  proponents  know  the  capabilities 
when  planning  investigations  of  critical  test  issues. 

ADST  is  at  the  center  of  a  rs^idly  changing  world  of  simulation  and  simulator  development  To 
ct^ture  ADSTs  role  in  .that  world  quires  the  creation  and  maintenance  of  an  ADST  system 
description  under  a  formal  configuration  management  program. 


1.2  Program  Phasing  and  Milestones 

ADST  maintains  a  detailed  software  development  schedule  for  each  Delivery  Ordei/CSCI’s.  The 
schedule  is  based  on  the  overall  program  schedule  as  well  as  on  a  comprehensive  software 
development  methodology,  based  on  Company  Standards  and  Procedures,  and  as  streamlined  to 
at^t  to  an  Op^tions  and  Maintenance  {xogram  like  /  J>ST.  The  determination  of  specific  major 
mili^ones  are  influenced  primarily  by  Contract  requirements  specified  in  each  Delivery  Order. 

Appendix  A  and  B  provide  current  status  of  the  program  at  the  time  of  preparation  of  this  plan. 
A{^ndix  B  provides  a  CM  activity  chan  depicting  current  milestones.  Both  plans  are  dynamic  and 
will  be  updated  as  required. 


1.3  Special  Features 

The  ADST  program  contains  a  number  of  p^uliarities  that  require  special  attention  and 
understanding  in  order  to  provide  the  Configunuion  Management  services  needed  to  establish  a 
firm  foundation  for  the  BDS-D  system  baseline.  Issues  described  in  the  following  paragraphs  that 
make  the  ADST  program  unique  are  as  follows: 

•  existence  of  a  research  and  developmoit  product  baseline, 

•  delivery  orders  that  rei»esent  ECP  like  changes  to  the  baseline, 

•  requirements  for  delivoy  order  funding  of  CM, 

•  parallel  development  efforts  with  no  baseline  control, 

•  multi-site  development  efforts,  and 

•  multiple  H/W  and  S/W  ccmfigurations. 
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The  ADST  Configuration  Management  (CM)  funding  was  provided  18  months  after  the  program 
started  under  the  BDS-D  Software  Support  Contract  Change  Proposal  (SWCCP).  This  effort  was 
designed  to  bring  a  poorly  documented  software  baseline  develop^  as  a  research  and  development 
effort,  running  at  3  different  sites,  on  poorly  documented  hardware  configurations,  under  baseline 
control.  The  objectives  of  the  baseline  control  activities  to  be  provided  are  as  follows: 

•  inventory  the  software, 

•  identify  the  various  software  configurations, 

•  identify  the  various  hardware  configurations, 

•  establi^  procedures  for  change  control, 

•  establish  procedures  for  reload  control, 

•  establish  build  procedures  for  each  software  configuration, 

•  provide  version  description  documents  for  the  various  builds, 

•  maintain  records,  audit  trails. 

•  support  muld  site  development,  and 

•  provide  a  development  environment  for  test  and  integration. 

The  funding  profile  for  the  CM  was  reduced  substantially  from  what  was  originally  proposed.  In 
order  to  maintain  a  subsistence  level  of  support  for  configuration  management  it  was  deemed 
necessary  to  have  each  delivery  order  fund  it's  own  CM  in  addition  to  the  sustaining  effort  This 
has  the  advantage  of  only  funding  additional  help  when  the  work  load  increases  above  what  the 
sustaining  effort  can  support  due  to  delive^  order  work,  and  then  reducing  the  staff  when  the 
work  load  decreases.  Problem  and  tracking  is  part  of  the  sustaining  effort  but  fixes  are  outside  the 
scope  of  the  CM  effort.  At  the  same  time  the  sustaining  effort  maintains  the  knowledge  of 
procedures,  builds,  and  configurations  required  to  maintain  continuity  for  the  program. 

Another  problem  being  addressed  by  the  SWCCP  is  that  of  development  that  took  place  when  no 
standards  or  procedures  were  in  place.  In  fact,  there  was  apparently  no  CM  control  beyond  the 
knowledge  in  the  heads  of  engineers  concerning  the  structure  and  organization  of  software  for  the 
various  simulators.  This  has  resulted  in  "builds"  that  are  incomplete,  undocumented,  software  that 
is  out  of  date,  utilizing  procedures  that  were  never  adequately  finish^,  to  perform  the  compilation 
and  links.  Slowly,  configuration  by  configuration,  engineering  expertise  1^  been  brought  to  bear 
to  resolve  these  problems.  Missing  files  have  been  identified  and  obtained,  build  files  corrected, 
and  procedures  put  in  place  to  address  the  turnover  and  release  of  software.  This  time  consuming 
process  requires  reverse  engineering  of  the  software,  and  analysis  of  the  interfaces. 

Another  element  peculiar  to  the  ADST  program  is  its  multi-site  development  -aspect  Utilizing 
electronic  netwoite  and  by  subcontracting  software  development  concurrent  development  is  able 
to  take  place  on  a  delivery  order.  This  requires  careful  coordination  to  ensure  that  software 
changes  to  the  same  module  are  identified  and  merged  prior  to  testing  and  integration.  A  tracking 
mechanism  for  software  Check-in  and  Check-out  has  been  developed.  A  review  cycle  will  be 
utilized  to  ensure  the  integrity  of  the  baseline  for  those  modules  where  concurrent  development  is 
taking  place. 

Finally,  ADST  has  to  deal  with  multiple  software  and  hardware  configurations.  One  delivery  order 
may  make  changes  to  a  simulator,  by  changing  its  hardware  and/or  software,  to  run  a  series  of 
experiments.  In  some  cases  the  changes  become  permanent,  and  in  other  cases  they  don't  Until 
the  sweep  was  funded  there  was  no  way  of  tracking  the  software  builds  to  a  required  hardware 
configuration.  That  has  chpged  with  the  institution  of  CM  procedures.  The  CM  organization  will 
be  able  to  archive  and  retrieve  old  builds,  clearly  identify  the  hardware  configuration  a  software 
build  runs  on,  and  provide  a  version  description  document  of  the  code  required  to  reconstruct  an 
experiment 
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In  smeary,  the  ADST  program  represents  a  lai^e,  complex  body  of  hardware  and  software, 
operational  at  several  different  sites  across  the  county.  To  successfully  implement  a  viable  and 
credible  configuration  management  program  requires  the  cooperation  and  participation  of 
government,  subcontractors,  wd  Loral  personnel.  This  plan  is  written  to  focus  and  present  a 
process  to  correct  the  inherited  baseline  and  continue  configuration  managment  practices 
throughout  the  lifecycle  of  the  program. 
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2.0  Organization 

The  ADST  Software  Support  team  and  the  ADST  Program  Office  will  be  supported  by  a  Software 
Configuration  Management  team.  Technical  authority  is  provided  by  die  ADST  Program 
Engineering  Office.  Figure  2'1,  Software  Support  Organization,  illustrates  the  organizational 
relationships  of  the  Software  Configuration  Management  team  to  the  ADST  Program  Office  and 
DO  Managers. 

Initial  CM  objectives  require  the  identification  of  the  SIMNET  6.6.1  software  baseline  and 
documentation  required  to  establish  the  various  configuration  baselines.  Loral  will  establish 
software  product  baselines  against  the  SIMNET  6.6.1  release  and  manage  continued  releases  as 
they  are  completed  on  existing  and  new  delivery  orders.  Configuration  reviews,  audits,  and  the 
formal  operation  of  the  Configuration  Control  Board  (CCB)  will  ensure  proper  application  of 
configuridon  control  and  establish  the  basis  for  status  accounting. 
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Figure  2-1.  Software  Support  Qiganization 
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2.1  Structure 


2.1.1  Structure  (CM) 

LORAL  WDL  responsibilities  for  Configuration  Management  are  assigned  to  the  ADST  Software 
Process  Control  S^tion.  LORAL  will  apply  CM  directives  and  operating  procedures  that  have 
been  established  at  the  Division  level,  and  are  responsive  to  Program  requirements.  LORAL  will 
provideCM  as  described  herein,  and  will  apply  the  standards  of  this  plan  to  subcontractors  as 
^propriate. 

Within  CM,  a  program  planning  and  supiMtt  function  will  establish  the  tailoring  of  routine  internal 
procedures  to  the  specific  progi^  requirements.  The  established  CM  team  will  provide  active 
program  support  for  coordinating,  monitoring  and  implementing  the  activities  that  restUt  in 
appropriate  configuration  identification,  control,  and  status  accounting.  Detailed  responsibilities 
include  the  following: 

a.  Assurance  that  the  configuration  of  all  deliverable  items  are  fully  identified. 

b.  Perform  Configuration  Management  Procedures  lAW  ADST  Software  Standard 
Operating  Proc^ures  (^pendix  C). 

c.  Establishment  and  maintenance  of  the  Software  Support  Library  (SSL). 

d .  Establishment  of  procedures  for  Software  build  loads  and  installation. 

e.  Traceability  of  changes  to  field  patches,  and  maintain  accurate  software 
configuration  data  for  each  site. 

f.  Assurance  that  configuration  data  of  all  delivered  and  in-process  equipment  is 
maintained. 

g.  Preparation,  maintenance  and  distribution  of  configuration  status  accounting 
reports. 

h .  Coordination  of.  and  preparation  for,  CCB  £K:tivities  and  CM  audits. 

i.  Exercise  of  change  control  resulting  from  Software  Problem/Change  Reports 
(SP/CR’s)  and  Engineering  Change  rtoposals  (ECP’s). 

j .  Maintain  SP/CR  status  for  all  SP/CR’s. 

k.  Baseline  documentation  maintenance. 

l.  Maintenance  of  Hardware  and  Software  fiiventoiy. 

m.  Development  of  ADST  CM  Software  Standard  Opoating  Procedures. 
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2.1.2  Connguration  Control  Boards 


2. 1.2. 2  Configuration  Control  Board  (CCB) 

The  Loral,  San  Jose,  WDL  Configuration  Control  Board  (CCB)  is  designated  as  the  Central  CCB 
(i.e.  single  control  point)  for  all  changes  to  the  established  BDS-D  software  product  baselines.  In 
order  to  ensure  consistency  between  the  site  development  changes  and  die  central  software 
baseline,  aU  CM  related  operations  require  communication  and  coor^aadon  in  cooperation  between 
the  San  Jose  CM  staff,  EKD  Managers,  and  Site  representatives.  The  Sites  will  apprise  the  CCB  of 
any  possible  or  proposed  changes  to  the  product  baseline.  The  respective  DO  Manager  and  Site 
Representative  will  review  and  approve  site  generated  SP/CR’s.  Configuradon  reviews  and  the 
CCB  will  ensure  proper  applicadon  of  configuradon  control  and  establish  the  basis  for  sutus 
accounting.  Uie  CCB  will  provide  acdve  program  support  and  establish  a  team  for  coordinating, 
monitoring,  and  implementing  change  control.  The  C<^  will  interact  with  the  LORAL  Orlando 
Program  l^gineering  Office,  Site  representadves,  and  with  the  customer  to  adjudicate  proposed 
changes  to  the  baselines.  Role  and  Responsibilides  for  the  CCB  are  defined  in  the  ADST  Standard 
Operating  Procedure,  SSOP-002,  in  Appendix  C. 


2.2  Authority  and  Responsibility 

An  overview  of  the  Loral  WDL  ADST  organizational  structure  as  it  relates  to  Configuration 
Management  is  presented  in  the  context  of  the  ADST  Program  Organizational  strucmre  was  shown 
earlier  in  Figure  2-1.  The  ADST  program  is  organized  under  a  Program  Management  Office 
(PMO)  that  directs  the  total  effort  This  office  employs  the  resources  within  the  LORAL  WDL 
Electronic  Defense  Systems  (EDS)  Software  Department  through  a  formal  work  tasking  and 
authorization  procedures.  Control  of  the  ADST  activities  is  exennsed  at  the  highest  level  by  the 
ADST  Program  Manager,  supported  by  the  ADST  Program  Engineering  Manager  (PEM)  who  has 
direct  responsibility  for  all  engineering  activities.  The  ADST  Software  Engineering  Supervisor, 
repotting  to  the  ADST  PEM,  has  full  responsibility  for  all  aspects  of  software  development  from 
requirements  analysis,  code  check-in,  through  software  releases.  He  is  supported  by  the  EDS 
Software  Process  Control  Section  for  Software  Configuration  Management  (SCM),  Software 
Systems  Administration,  methods,  standards,  and  metrics. 

The  EDS  Software  Process  Control  Supervisor  reports  progress  and  status  to  both  the  Software 
^gineering  Supervisor  and  to  the  ADST  Program  Engineering  Manager  (PEl^,  thus  providing  an 
independent  re^rting  path.  Software  quality  evaluations  are  performed  by  the  Software  C^ality 
Assipince  (SQA)  organi^on  (which  is  independent  from  the  ADST  Program).  This  independent 
quality  assurance  crqiability  ensures  that  all  processes  are  conducted,  and  that  all  products  are 
developed,  in  accordance  with  contract  requirements  and  that  Configuration  Management  is 
conducted  in  accordance  to  this  CM  Plan.  The  Baseline  Configuration  is  maintained  by  the 
Software  Configuration  Management  (SCM)  Analysts  and  Software  Systems  Administrator  who 
ate  members  of  the  EDS  Software  Process  Control  (SPC)  Group. 

The  CCB  will  convene  on  an  as  needed  basis  and  will  be  composed  of  members  from  the  Program 
Office,  DO  Managers,  Software  Engineering,  Systems  Engineering,  Configuration  Management, 
Test,  Software  (JuaUty  Assurance,  Sites  and  CJovernment  (STRICOM)  representation.  Actions  of 
the  LORAL  CCB  will  include  verifying  compliance  with  contractual  requirements  and  ensuring  the 
identification,  evduation  and  consideration  of  the  technical  reasons  for  changes(s).  Members  of 
the  CCB  will  advise  the  Chairman  (ADST  PMO  or  designee),  regarding  the  impact  that  proposed 
chan^  will  have  in  the  areas  of  costs,  production,  and  documentation  support. 
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2.3  Policy  Directives 

An  independent  CM  organization  with  defined  responsibilities,  policies,  and  procedures  that 
comply  with  ADST  program  requirements  has  been  established  in  compliance  with  policy 
directives.  Process  control  and  configuration  management  practices  have  been  tailored  for  the 
ADST  program  using  Company  directives  and  standards  from  the  LORAL  WDL  Software 
Ftoducuvity  Laboratory  and  the  ^ftware  En^iuering  Process  Group. 


2.4  Reference  Documents 

Government  Documents: 

MILrSTD-14S6A  Configuration  Management  Plan 


Non-Government  Documents: 


ADSTSSOP’s 

ADSTLWDL 

ADSTLWDL 

ADSTLWDL 

ADST  WDiyrR-92-03014-QIRl  YR2 


ADST  Software  Standard  Operating 
Procedures  -  CM  Procedures 

Documenadon  Plan  for  the  ADST  Program 

Software  Quality  Program  Plan  Gn  process) 

Software  Development  Plan  (In  process) 

System  Definition  Document 


Software  Productivity  Lab  (SPL)  Documents 

VoL  1  Corporate  Standards  Methods 

Vol.  2  Sof^ate  Engineering  Practices 
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3.0  Baseline  Identification 

The  ADST  team  approach  to  managing  the  software  life  cycle  will  be  based  on  establishing  a 
product  baseline,  ’ne  Product  Baseline  (initially  SIMENT  Version  6.6.1)  will  be  used  as  the 
starting  baseline  for  subsequent  design  devdopment  and/or  DO’s.  Changes  to  the  product  baseline 
will  be  established  to  define  a  formal  departure  point  for  control  of  future  revisions,  or  deliveries. 
In  the  event  that  a  new  simulate  is  devdoped,  configuration  identification  will  be  established  in  the 
form  of  technical  specifications  for  the  system,  die  system  segments,  and  each  Configuration  Items 
(CI/CSCI).  Hence,  Functional  Configuration  Identification  (FCI)  will  be  established  against 
performance  orient^  requirements  for  the  segment  design  and  p^ormance. 

The  ADST  project  involves  the  development  and  maintenance  of  many  complex  software 
components  which  execute  on  several  hardware  platforms.  The  project  software  development  is 
not  for  the  purpose  of  achieving  one  delivery,  rdh«’  fix'  the  purpose  of  achieving  multiple  rdeases 
with  polenaal  increasing  capabUities  for  a  particular  configuration. 

The  elements  below  comprise  the  Engineering  groundwork  required  to  support  a  DO  Software 
release  process.  The  elements  required  for  a  DO  package  may  vary  based  on  requested 
sponsor^p  and  will  be  funded  with  each  DO.  The  release  kit,  including  the  code  is  for  general 
release  unless  specified  by  the  customer.  The  information  required  forms  Ae  basis  for  the  *i^liver 
Order  Release  Kit"  (SSOP-0009): 

•  Delivery  of  a  Version  Description  Document  depicting  the  contents  of  the  build 
release.  Including  associated  open  and  closed  SP/CR’s.  The  VDD  will  be 
distributed  on  floppy  disk  along  with  a  hardcopy. 

•  Provide  required  executable  code,  object  code,  data  files,  tables  and  parameter  files 
to  bring  up  a  system.  Include  a  read.me  file  with  appropriate  header  information  to 
identify  tapes  for  loading  software. 

•  Coldstart  procedures. 

•  Identification  of  the  hardware  configuration  required  by  a  sofiwware  release. 

•  Installation  procedures. 

•  Build  and  distribution  instructions. 

•  Identification  of  known  problems. 

•  Regression  test  results. 

•  Reference  to  the  Acceptance  Test  Plan  for  used  recertify  that  a  configuration  has 
been  restored  to  its  "baseline”  configuration. 

•  English  narrative  synopsis  of  functionality  of  the  released  system. 

•  List  of  documents  {q)plicable  to  the  configuration. 

•  Release  Notes,  if  appropriate,  depicting  notes/differences/compatibility  since  the 
last  rdease. 
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•  Provide  tools  to  support  any  necessary  on-site  regressitm  testing. 

•  Provide  POC  (name^hone  number)  for  eadi  release. 

•  User  Guides  (as  funded  by  a  DO). 

Configuration  IdentificadcHi  and  control  is  maintained  throughout  all  software  development  phases. 
The  following  products,  as  required  by  the  ^nsoring  organziation  will  be  maintained  by  tbs 
ADST  Software  Ctmfiguration  Manager 

•  Software  Development  Plan  (SDP) 

•  Ctmfiguration  Management  Plan  (CMP) 

•  Software  Requirements  ^sedfications  (SRS) 

•  Inteafaoe  Requirements  Specification  (IRS) 

•  Software  PrMua  Specifications  (SPS) 

•  Software  Test  Plans  (STP) 

•  Software  Test  Descripticms  (STD) 

•  Software  Development  Files  (SDF) 

•  Software  Design  Documents  (SDD) 

•  Interface  Design  Documents  (IDD) 

•  Veraon  Desertion  Documents  (VDD) 

•  Software  Maintenance  Manuals  (SMM) 


3.1  Product  Baseline 

The  product  baseline  will  be  established  for  tl»  system  by  the  Q  software  product  specification 
after  successftil  completion  of  an  informal  LORAL  WDL  Functional  Configuration  Audit  (FC  A) 
and  Physical  Configuration  Audit  (PCA)  for  each  CSCL  The  product  baseline  include  the 
identification  erf  evolving  source  code  and  softwae  build  loads  (executable  cocte). 


3.1.1  Specifications 

As  q)plicable  for  a  Delivoy  Order,  the  product  baseline  will  be  documented  in  the  Software 
Product  Spe^cations  and  Interface  Spectficatiems.  In  the  case  of  SIMNET  6.6.1,  however,  the 
product  baseline  is  defined  without  any  underlying  CSQ  structure. 


3.1.2  Drawings  and  Associated  Lists 

Drawings  are  to  be  prepared  to  WDL  DPM  practices  and  on  WDL  drawing  format  All  drawings 
will  be  prepwd  to  Level  I  requirmnents  u^ess  otherwise  stated  in  the  contract/delivery  order. 
Drawings  originating  within  WDL  San  Jose  and  at  Orlando  and  any  other  locations  will  be 
submitted  to  the  ADST  PMO,  WDL  San  Jose  CCB  review/release  to  the  Engineering  Data 
Management  System  (EDMS)  database.  Custodial  release  is  autiiorized  as  the  cost  effective 
drawing  control  approach  to  this  prototype  development  research  and  analysis  type  system. 
Custodial  release  is  described  in  the  Documentation  Plan  for  the  ADST  Program  available  from 
CM. 
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4.0  Connguration  Change  Control 

The  purpose  of  change  control  is  to  prevent  incorrect  or  unapproved  changes  from  taking  place 
while  expediting  the  approval  and  implementation  of  formally  approved  chwges.  These  changes 
are  grou^  into  the  following  categories: 

a.  Software  Problem  Fixes 

b.  Hardware  Problems 

c.  Documentation 

d.  Firmware 

e.  DeUveiy  Order  (DO)  software  updates 

In  addition  to  change  decision  making,  change  control  includes  the  equally  important  functions  of 
setting  change  priorities  (emergency,  urgent,  or  routine)  and  of  assuring  that  necessary  instructions 
ate  issued  promptly  for  approved  change.  Internal  change  control  will  be  applied  to  the  entire 
software  pt^ua  throughout  the  development,  maintenance,  and  informal  test  ph^. 

Change  control  of  the  product  baseline  is  tracked  through  the  use  of  the  Software  Problem/Change 
Report  (SP/CR)  form.  The  SP/CR  is  the  vehicle  used  intenudly  to  report  a  known  or  suspected 
anomaly  in  the  developmental  configuration  for  software,  hardware,  firmware,  or  documentation. 
The  SP/CR  ;»xx:eduies  and  guidelines  are  described  in  ADST  SSOP’s<(XX)3  and  (X)06. 


4 . 1  Responsibilities 

The  ADST  CCB  proce^  is  to  assess,  review,  and  evaluate  the  necessity  for  proposed  changes  to 
^proved  product  baselines.  Release  of  new  design(s),  and  changes  to  approved  baselines  require 
i^proval  of  the  Loral  WDL  CCB.  The  CCB  is  chahn^  by  the  Loral  ADST  Program  Manager  in 
San  Jose,  and  is  composed  of  senior  members  of  the  various  support  organizations  including 
Software  Configuration  Management  The  CCB  will  meet  on  an  as  needed  basis,  the  frequency 
and  time  of  meetings  to  be  determined  by  the  chairperson.  Detailed  membership  and  roles  and 
responsibilities  for  the  CCB  ate  described  in  SSOP-2,  XCB  Charter". 

The  sites  ate  delegated  ^  authority  to  approve  site  implemented  SP/CR’s.  Each  site  will  have  the 
responsibility  to  maintain  the  developed  products  in  ate  development  directories.  Once  functional, 
Ae  products  be  transmitted  back  to  the  San  Jose  CM  team,  reviewed  at  the  Central  CCB  and 
incorporated  into  the  SSL  baseline  repository.  Procedures  for  site  turnover  of  code  and 
documentation  are  outlined  in  SSOP-(XX)7.  The  Central  OCB  will  mediate  coiiflicts  between  sites 
due  to  changes  (hardware,  firmware,  and  software  product  configuration  items)  and  analyze 
proposed  DO  updates  to  a  software  product  baseline.  Release  of  specifications,  new  design(s), 
and  changes  to  ^proved  baselines  requite  ^proval  of  the  CCB. 

Configuration  Management  will  control,  document,  and  distribute  all  software  releases  to  the  test 
and  target  environment  in  the  Loral  Sof^ate  Development  Facility  (SDF),  as  well  as  to  the 
operational  sites.  It  will  be  configuration  management’s  responsibility  to  create  software 
construction  procedures  which  w  repeatable  for  any  revision  that  been  introduced  into  the 
Software  Sujqxxt  Library.  CM  will  document  the  exact  configuration  of  all  hardware  and  software 
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used  during  test  and  integration.  A  conqxehensive  list  of  all  hardware  and  software  configuratians 
in  the  Loru  SDF  are  nuuntained  in  die  ADST  System  Defimtum  Document 

4.2  Procedures 


4.2.1  Software  Configuration  Control  Process 

The  primary  reporting  mechanism  for  changes  to  the  BDS-D/DO  system  configurations  is  via  the 
Software  Problem/C^ge  R^tt  The  SP/CR  is  used  by  the  sites  and  the  CCS  to  resolve  design 
and  document  issues  to  the  CM  controlled  software  budine.  An  SP/CR  status  repmt,  which 
serves  as  the  agenda,  is  prepared  and  distributed  by  Configuration  Management  in  a  timely  manp^g- 
to  support  the  functions  of  the  Board.  Since  the  CCB  representatives  may  be  located  at  various 
facilities,  technical  interfacing  will  be  accomplished  via  the  conference  phone. 

The  following  is  the  detailed  process  fiow(s)  associated  with  eadi  SP/CR: 

a.  Accept  the  SP/CR.  Evaluate  cost,  schedule  and/or  project  performance.  Evaluate  whether 
or  not  the  requested  change  is  a  common  software  product  change  or  a  site  unique  change 
Review  responsibility  to  work;  task  software  engineer  to  implement  the  change. 

b.  Defer  the  SP/CR  for  further  study.  If  the  change  is  out-of-scope  of  the  LSE  contract,  direct 
Systems  Engineering  to  prepare  documuitadon  for  subsequent  approval 

c.  Disapprove  SP/CR.  Notify  originator  of  documented  disapproval;  close  SP/CR. 

d.  Identifying  problems  and  request  funding  for  out-of-scope  issues. 

Status  on  aU  of  the  above  acticms  ftom  the  CCB  will  be  provided  to  the  ADST  Program  Office  and 
the  Delivery  Order  Mangers. 


4.2.2  Software  Problem/Changc  Report  (SP/CR)  Processing 

The  SP/CR  provides  the  means  for  rqrorting  errors  in  development,  test,  and  operational  software 
and/or  hardware.  An  SP/CR  is  completed  b>  any  user  or  developer  who  discovers  a  system 
anon^y,  or,  desires  a  modificatirai  in  order  to  improve  system  opnational  efficiency.  The  SP/CR 
provirkis  a  formal  means  for  recording  all  software  and  hardware  faults  «nri  modification  requests. 
Each  SP/CR  will  be  submitted  to  the  CCB  or  respective  site  representative/DO  Manager  for 
analysis.  SP/CR*s  which  ate  out  of  scope,  such  as  beyond  the  normal  schedule,  scope  of  current 
activities,  budget  or  enhancements/improvements  will  be  forwarded  to  the  LORAL  WDL  Program 
office  for  resolution.  Figure  4-1,  Change  Process,  provides  an  overview  of  the  ADST 
softwate/change  correction  process. 

After  software,  hardware,  and  documentation  are  placed  under  configuration  control,  all 
modifications  to  these  products  require  an  SP/CR.  The  SP/CR  assignee  is  authorized  to  resolve  a 
problem  only  by  being  designated  by  an  approved  SP/CR.  The  SP/CR  resolution  must  be  verified 
by  peer  review  before  recommending  closure  of  the  SP/CR.  The  on-line  history  in  the  code  must 
be  updated  along  with  associated  documentation ,  including  build  requirements  to  reflect  specific 
changes.  When  completed,  the  assignee  then  coordinates  the  recommended  closure  of  the  SP/CR 
with  the  Software  Configuration  Manager.  No  SP/CR  is  closed  until  successful  completion  of 
verification  and  test  with  CCB  concurrence  or  the  Site  Repiesentative/DO  Manager 
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1.  Sites  discover  problon, 
generate  SP/CR  rqxxts, 
including  analysis. 

2.  SSL  using  4D  logs  problems 
and  submits  to  the  CCS. 

3.  Site/CCB  analyzes  problem 

a.  Within  scope  of  LSE? 

b.  Relevant  to  cutrem  DO? 

c.  Out  of  scope? 

Ifaorb 

4.  Engineering  fixes  problem 
and  conducts  approprite  tests. 
Submits  fixes  to  CM/SSL 

5.  CM/SSL  logs  fixes  and 
submits  to  CCB. 

6.  Site/co  reviews  fixes  and 
approves  update  to  the  baseline. 

7.  CM/SSL  updates  the  baseline 
and  releases  it  to  the 
I&T/Site. 


Hgure4-1.  Change  Process 


The  ADST  SP/CR  system  is  a  multi-user,  multi-site  Software  Problem  Reporting  iy)plicati<»i  using 
the  4th  Dimension  Data  Base  Management  System  (DBMS).  The  SP/Ql  system  is  located  at 
LCXIAL  WDL  and  can  be  accessible  fiom  eadi  site  with  Ae  in^allatioo  of  the  4D  Runtime  License. 
The  SP/CR  system  is  a  menu-driven  tool  with  data  accessibility  ^vided  into  four  groups;  the 
submitter,  the  iq>prover,  tire  assignee,  and  configuration  management  An  ADST  SP/CR  User’s 
Manual  will  be  available  on-line.  The  procedures  are  documented  in  SSOP-(X)03.  Ingure4-2isa 
sample  of  the  SP/CR  form.  SSOP  (XX)3  shows  samples  of  the  SP/CR  data  base  menus. 
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PARTI 


ORIOINATOR 


SP/CR  Form 


DATE: 


SP/CR  NUMBER: 


PRIORITY 

SCOPE 

Q  Critical 

Q  Sgctaai 

Q  Sarlaas 

Q  Sahc|*tan 

Q  Hlaar 

Q  Salt/Canpaaaat 

Seftwar*: 

Hardwara: 


PHASE 


DO/CONFIQURATION 


AREA 

O  RBI 
Q  SOI 

Qbsc 


PROPOSED  SOLUTION: 


PARTS 


PROBLEM  RESOLUTION 


PARTS! 


AS8IGNEE(S) 


STATUS: 
DISPOSITION: 
METRIC  CATEGORY: 


DATE: 


UE  DATE  OPEN  APPROVAL 

NAME: 

DATE: 


C.M.  SIGNATURE 
NAME: 

DATE _ 


CLOSE  APPROVAL 
NAME: 

DATE: _ 


Hgure  4.2.  SP/CR  Form 
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4.2.3  Software  Change  Control 

Tbe  control  process  for  each  jxt^uct  or  Delivery  Orxter  (DO)  under  development  adhoes  to  a  set  of 
activities  th^  is  accompli^d  in  a  particular  order  to  conform  to  the  building  block  ^proach  of 
SP/CR  validation  and  verification.  The  CM  tools  and  directory  structure  provide  CM  with  tte 
ability  to  uniquely  identify  and  build  a  DO  product  baseline.  In  this  process  there  are  related 
phases  that  provide  the  abUity  to  incrementally  build  on  a  foundation  of  a  tested,  controlled,  and 
validated  baseline.  There  is  one  CM  library  area  that  is  managed  and  maintained  by  the  CM  team. 
This  domain  is  referred  to  as  the  Software  Support  Library,  (SSL)  described  in  rarther  deu^  in 
paragraph  4.2.S  below.  An  identical  structure  is  created  from  the  CM  area  for  developers  to 
perform  upgnutes.  Here  developers  code  and  build  their  changes.  After  successful  development  / 
unit  test  on  the  target  machine,  the  change  is  turned  over  to  CM  for  control  and  incorporation  into 
the  CM  baseline  via  an  approved  SP/CR.  Figure  4-3  provides  a  graphical  view  of  the  CM 
structure. 


Figure  4-3.  SSL  Structure 

The  CM/SSL  Baseline  structure  is  a  controlled  environment,  which  provides  protection  from 
unauthorized  software  changes.  It  contains  modules  which  have  been  identified  by  software 
engineers  for  control  and  are  managed  by  the  Configuration  Management  team  under  the  Revision 
Control  System  (RCS)  or  other  CM  software  packages  as  applicable.  These  modules  have  been 
built  (compiled  and  hni^)  to  prodtp  an  implication  build  load  or  Delivery  Order  (DO).  A  build  is 
defined  as  the  compilation  and  linking  of  source  code  into  the  program  executable  images  that  run 
on  the  target  simulator.  Included  as  part  of  the  bmld  are  any  data  files  or  databases  requir^  to 
initialize  and/or  supprt  the  execution  of  die  programs  in  the  simulators.  Each  build  load  is  fiaggftri 
via  RCS  with  a  revision  number  associated  with  the  particular  DO.  Changes  to  software  modules 
will  be  identified  by  an  SP/CR  number  in  the  header  /  prologue  block  of  the  source.  The  SP/CR 
will  remain  open  until  the  change  has  been  validated  through  regression  testing  in  a  closely 
monitored  integration  environment 
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The  develoinnent,  test,  and  (^)erational  software  baselines  are  maintained  in  directory  structures  on 
the  target  maghin^  under  the  SSL  that  are  closely  monitored  by  CM.  The  CM  BaseUne  directories 
contain  a  snapshot  of  the  controlled  baselines,  which  can  be  used  to  recreate  a  given  environment 
The  Operational  Baseline  directory  contains  software  which  has  been  derived  mmi  some  baseline, 
upgra^,  tested,  controled,  and  labeled  “operational”.  This  directory  and  all  subdirectories  are 
under  CM  control  by  use  of  operating  system  protections.  The  Test  Baseline  directory  contains  a 
CM  built  baseline,  which  is  not  yet  operational.  Formal  testing  of  software  “captured”  from 
devdopers  is  performed  in  this  area.  When  this  testing  process  has  determined  that  the  software  is 
working  properiy,  it  is  moved  into  the  Operaticmal  baseline  directory  by  CM. 

The  Development  Baseline  area  is  where  build  loads  are  downloaded  and  distributed  to  the 
designated  devdopment  configurations  in  the  SDF  for  SP/CR  incorporation  and  further 
development  and  unit  testing. 


4.2.3. 1  Development  Phase  Change  Processing 
The  software  development  and  build  process  is  divided  into  three  areas: 

a.  SP/CR  Initiated/Code  Controlled 

b.  Regression  Test/Close  SP/CR 

c.  Tested  Baseline 

The  development  and  build  process  will  be  coordinated  with  all  sites  at  the  LORAL  WDL  Software 
Development  Facility.  For  all  sites,  the  SP/CR  initiates  the  introduction  of  new  source  into  the 
basel^e  or  identifies  a  need  for  change  to  source  already  under  CM  control.  The  build  cycle  starts 
when  an  SP/GR  is  submitted  for  open  approval  by  an  originator  and  ends  when  the  source  files  are 
turned  over  to  CM  and  placed  under  control.  l4o<»dures  for  checking  code  in  and  out  from  the 
CM  SSL  are  identified  in  ADST  SSOPs  0005  and  0007. 

Once  a  completed  SP/CR  has  been  generated,  the  engineer  ensures  that  it  contains  all  pertinent  data 
including: 

a.  description  and  proposed  solution  of  change, 

b .  priority  of  change 

c.  source  files  affected  by  change,  and 

d .  identification  of  obvious  dqrendencies  (other  affected  source  files)  with  change. 

As  a  result  of  formalized  reporting  utilizing  the  SP/CR  process,  similar  (related/dependent)  errors 
may  be  coordinated  and  schedule  with  an  alternate  site  at  the  same  time.  It  is  important  that  a 
software  change  does  not  create  problems  in  other  software  source  files. 

If  an  SP/CR  is  error  free,  the  source  is  controlled  and  all  SP/CR  dependencies  are  identified.  In 
this  way  the  configuration  manager  maintains  the  internal  consistency  and  correctness  of  the 
baseline. 
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4. 2. 3. 2  Integration  and  Test/Change  Processing 

After  a  package  of  software  is  completed  it  must  be  tested.  In  coordination  with  the  site  engin^, 
CM  will  construct  the  build  configuration  to  support  testing  in  the  SDF.  The  goals  of  CM  during 
Unit  and  Formal  testing  are  to  minimize  divergence  between  baselines;  tdlow  the  software 
engineers  to  find  and  ^  bugs  quickly;  and  to  build  a  project  baseline  containing  validated  code. 
To  provide  the  softwaie  engineers  at  tdl  sites  with  a  ctanpletely  stable  test  environment,  a  read  (xily 
copy  of  the  current  built  baseline  will  be  made  available  to  the  site  r^ponsible  engineer.  This 
ftnabies  the  ^nginfifir  to  make  a  copy  of  the  stable  CM  controlled  baseline,  and  compile  and  link 
within  their  workspace,  without  aiffecting  other  development  performed  concurrently.  The 
engineer  is  able  to  confi^ndy  test  against  the  most  current  baseline  before  turning  the  completed 
so^are  over  to  CM.  During  the  Integration  and  Test  Phase  the  Integration  and  Test  Manager 
provides  a  selected  list  of  SP/CRs  to  be  included  in  the  build.  All  SP/CRs  included  on  this  list 
have  been  turned  over  and  revalidated  by  CM,  approved  by  the  Site/CCB,  and  a  dependency 
analysis  has  been  performed  against  the  listed  SP/CRs  and  the  controlled  baseline.  CM  then  copies 
the  files  associated  with  the  SP/CRs  indicated  in  the  selected  list,  performs  the  build  in  the 
appropriate  directoiy  tree,  and  distributes  the  softwaie  to  the  appropriate  SDF  Development  and 
Integration  and  Test  machines.  Distribution  Procedures  are  documented  in  SSOP  0010.  Figure 
4-4  depicts  the  process  flow. 


UTSPR 


TURNOVER 


BASE  MOLD  BUILD 


Figure  4-4.  Development/CM/I&T  Process  Cycle 


4. 2. 3. 4  Site  Integration  Change  Processing 

Any  changes  to  a  build  during  Site  Integration  will  be  made  in  development  directories  in  a  Site 
Integration  Development  environment  An  SP/CR  will  be  generated  for  all  required  changes.  The 
code  will  be  modiiied,  tested,  and  the  corresponding  SP/CR  submitted  to  the  Site  Representative 
and  DO  Manager  for  approval.  The  CCB  will  review  the  SP/CR  and  those  SP/CRs  receiving 
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approval  from  site  will  be  incorporated  into  the  baseline  libraries.  The  board  will  have 
r^resentatitm  from  all  software  efforts  under  tire  ADST  umbrella  and  thus  the  impact  of  code 
modifications  can  be  assessed  at  this  time.  If  the  code  under  review  will  furth^  impact  other 
efforts,  it  will  be  determined  whether  this  code  will  go  into  the  common  set  of  baselined  code,  or 
odrer  specific  baselines.  Change  control  for  Field  Su[^rt  is  identified  in  SSOP-0013. 


4. 2. 3. 5  Merging  Software  Baselines 

Devdqnnent  of  changes  may  take  place  at  difGuent  sites.  During  this  multi-site  development  effort 
there  will  be  divergoit  paths  that  need  to  be  merged  together  at  discrete  points.  These  discrete 
points  or  software  revisions  will  be  evaluated  with  rega^  to  criticality  to  the  user  and  developer 
and  revision  priorities  will  be  established  by  the  joint  agreement  between  the  Site  and  the  C(^. 
The  merge  process  is  required  when  the  official  baseline  has  been  changed  by  another  development 
effort.  All  changes  developed  using  the  original  SSL  CM  baseline  as  the  starting  point  are 
identified  and  are  integrated  into  the  CM  baseline  at  the  SSL  to  produce  a  new  combiii^  version. 
A  module  diat  has  been  identified  as  being  modified  at  more  than  one  site  will  be  compared,  and  if 
necessary,  a  responsible  software  engineer  will  be  required  to  perform  the  merge.  I^or  to 
controlling  the  source,  CM  will  recompile/relink  all  source  and  perform  an  impact  assessmrat 
against  the  controlled  baseline  prior  to  CCB  review. 


4.2.4  CM  Software  Release  Naming  Conventions 

Standard  naming  conventions  are  to  be  used  when  establishing  new  and  revised  BDS-D  software 
versions.  The  accepted  convention  will  be  used  for  renaming  existing  6.6.1  baseline  versions  and 
for  new  baseline  versions. 

Example 


BDS-D  RWA  Bufld  Version  1.1.0 
1.  s  Major  Revision,  implies  functionality  change 
1.1s  Mmor  Revision,  implies  improvement 
1.1.0  =  Correction  Revision,  implies  bug  fixes 


4.2.5  Software  Support  Library  (SSL) 

The  ADST  Software  Support  Libra^  (SSL)  will  be  established  at  LWDL  San  Jose,  as  an  access- 
controlled  enviroiunent  for  controlling  the  storage,  handling,  and  release  of  software  and  related 
documentation  to  all  supported  BDS-D  sites.  Major  SSL  functions  include  the  following: 

a.  Checkin ,  validate,  and  place  under  CM  control  source  code  and  all  related  libraries 
ddivraed  via  acquisitions  from  subcontractors. 

b.  Generate  software  masters  and  copies. 

c .  Generate  source/executable  object  programs  on  protected  media. 
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d.  Provide  im>tecti<»  frcMD  unaudiorized  program  changes. 

e.  Receive  and  incaqx>raie  i4){xoved  source  code  changes. 

f .  Ensure  that  changes  are  incorporated  in  related  software  documentatiort 

g.  Maintain  SP/CR  databases. 

h.  Receive  and  store  test  data  and  programs  £(»*  veiificaticm  testing. 

i.  Provide  source  and  lest  data  for  development  and  testing  of  software  changes. 

j.  I¥ovide  centralized  storage  of  reference,  baselined,  and  deliveraUe  (tocuments. 

k.  Maintain  a  tape  backup  Ubrary  for  all  vendor  software  used  on  die  development  and  target 
machines. 

The  CM  tools  and  director  structure  provide  the  group  with  the  ability  to  uniquely  identify 
and  build  a  specific  baseline.  There  is  one  CM  library  area  that  is  manag^  and  maintainftH  by 
Software  Cmifiguration  Management  (SCM).  Source  files  in  this  library  are  marked  with  a  unique 
version  control  number  and  e^  changed  module  is  associated  with  an  SP/CR  identifier  in  the 
header  of  the  source.  The  SP/CR  remains  open,  however,  until  the  fix  has  later  passed  regression 
testing.  Modules  that  check  out  successfully  are  put  under  CM  control.  A  copy  of  the  software 
identified  by  the  SP/CR  is  placed  in  a  holding  area  and  waits  until  called  upon  by  ^  test  team  to  be 
included  in  a  build.  Procedures  for  this  process  are  identified  in  SSOP  #0007.  Wlren  the  SP/CR 
identified  software  is  selected,  a  copy  from  the  controlled  area  is  moved  to  a  build  area  and  built  by 
CM.  If  the  built  software  fails  during  test  it  is  reassigned  to  the  cognizant  engineer  for  rework, 
which  will  require  a  CM  revalidation,  reccnnpile  and  relink. 

The  storage  and  maintenance  of  the  ADST  software  products  shaU  be  cmitralized  in  an  autmnated 
SSL  environment  which  is  the  responsibility  of  dte  Configuration  Manager.  This  on-line  library 
resides  on  a  SUN  SPARCserver.  The  software  cmifiguration  management,  library  control,  and 
system  build  facilities  are  performed  under  the  mittHnated  techniques  of  the  SUN/Ufnx  RCS 
(Revision  Ctmtrol  System)  code  management  systmn  and  die  Make  ciqiability  (an  automated  build 
tool). 

The  SSL  provides  unique  identification  of  all  baselines,  programs,  documents,  tools  and 
procedures  entered  into  the  library.  CM  prepares,  maintains,  and  periodically  diMftminatffs  an  up- 
to-date  index  of  all  items  in  the  library.  CM  prepares,  logs,  and  maintains  Software 
Problem/Change  Reports  in  the  SSL  and  provides  approved  users  wiA  the  latest  CSCI  baselines, 
terrain  ^tabases,  supporting  documentation,  and  prepares  and  submits  software  Version 
Descr^on  Documents  (VDDs)  for  each  formal  release. 

CM  has  the  prim^  fimction  and  responsibility  for  maintenance  and  control  of  all  baselines  and 
on-line  ctmfiguration  items.  Only  the  CM  staff  may  access  controlled/baselined  library  information 
and/or  files. 
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A  CM  library  hierarchy  has  been  established  and  includes  separate  RCS  libraries  for  the  specific 
baselines.  Included  in  each  baseline  are  source  code,  test  pla^,  and  documentation.  This  libnuy 
hierarchy  mirrors  each  vehicle  and  simulation  subsystem  development  directory  structure,  thus 
facilitating  the  transfer  of  data  while  maintaining  consistency  of  i^ntification  and  design.  Bgure 
4-5  is  a  sample  of  a  high  level  overview  of  the  BDS-D  SSL  duectory  structure. 


Figure  4-5.  SSL  Directory  Structure 


4.2.6  CM  Tools/Build  Environment 

A  collection  of  tools,  as  described  below,  have  been  installed  for  code  control  and  building  of 
software  files.  In  addition,  tools  using  UNIX  script  files  have  been  prepared  to  automate  and 
streamline  the  process  of  code  control. 


4.2.6. 1  Revision  Control  System  (RCS)/Concurrent  Version  System  (CVS) 

Revision  Control  System  (RCS)  is  a  program  librarian  for  the  tracking  and  control  of  hfl«»lined 
software  in  the  UNIX  Environment  This  on-line  system  maintains  baselined  files  in  project 
libraries.  RCS  keeps  the  original  versions  of  library  files  and  dien  tracks  the  changes  to  the  project 
library  by  storing  the  changes  made  with  each  retrieval  and  replacement  file  in  the  library.  As  a 
result  RCS  reconstruct  any  previous  veruon  of  a  project  fUe.  In  ad^tion  to  storing  successive 
changes  to  library  files,  RCS  monitors  library  access  and  keeps  a  historical  record  of  library 
access.  By  entering  RCS  commands,  the  CM  Staff  can  easily  retrieve  information  about  library 
transactions  and  contents.  It  provides  CM  and  program  management  with  an  excellent  status 
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accounting  tool  for  version  descriptions,  and  annotated  file  listings.  This  tool  will  be  used  to  tag 
classes  of  a  build  to  aid  in  the  configuration  identificadon  and  movement  of  code  to  build  areas  and 
maintenance  of  baseline  areas.  The  Concurrent  Version  System  (CVS)  is  a  layered  product  on  top 
of  RCS.  The  CVS  tool  provides  automadon  of  repeddve  RCS  tasks  and  facilitates  in  the 
implementadon  of  software  identificadon  and  control. 


4. 2. 6. 2  Version  Master  System 

The  Version  Master  System  is  a  program  librarian  for  the  tracking  and  control  of  baselined 
software  in  the  Macintosh  Environment  and  provides  similar  funcdonality  as  the  RCS  system 
described  above. 


4.2.6.3  MAKE 

UNIX  Operating  System  along  with  RCS  provides  an  automated  build  tool  called  MAKE.  MAKE 
automates  and  simplifies  the  building  of  software  systems.  In  the  development  of  a  large  software 
system  many  of  the  dependent  source  files  are  typically  in  various  states  of  compledon.  When 
changes  are  made  to  the  software  system,  MA^  determines  which  source  files  need  to  be 
recompiled,  and  ensures  the  software  system  is  recompiled  and  linked  with  all  the  latest  changes. 
MAKE  interacts  with  RCS  and  extracts  files  from  the  RCS  libraries  when  building  new  object 
files. 
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5.0  Interface  Management 

Loral's  Program  Engineering  Manager  (PEM)  will  be  responsible  for  integrating  all  functions  for 
the  engineering  aspects  of  the  contract  The  PEM.  supported  by  the  Process  Control  Supervisor 
will  be  responsible  for  ensuring  that  stated  CM  ta^  are  accomplished  to  program  standards,  on 
time,  and  within  budget  Hie  Process  Control  Supervisor  will  also  be  responsible  to  the  I^ogram 
Manager  for  assessing  and  reporting  the  cost  impact  of  CM  requirements  on  the  actions  of  all  other 
functions  in  the  program  during  the  course  of  tte  contract 


5 . 1  Documentation 

The  configuration  management  process  must  support  a  fast  and  accurate  decision-making  process 
for  proposed  engineering  changes.  Baseline  documentation  must  be  maintained  throughout  the 
development  and  operational  process. 

Currently,  ADST  assets  are  only  partly  documented.  Documents  may  not  reflect  changes  or 
revisions  made  to  the  ADST  equipment  and  no  formal,  coordinated  process  has  been  used  to 
review  and  approve  changes.  The  minimal  set  of  documentation  must  be  identified  by  the 
configuration  control  board  and  supplemental  documentation  for  existing  SIMNET-D  equipment 
procedures,  and  data  must  be  brought  under  configuration  management 

Supplemental  documentation  is  the  equipment  documentation  and  manuals  prepared  by  the  ADST 
systems  engineering  organization  bas^  on  theii  assessment  of  the  current  configuration  and  status 
of  all  government  furnished  ADST  equipment  documentation  and  manuals.  Supplementary 
documentation  is  required  for  two  purposes:  (1)  to  support  the  maintenance  and  enhancement  of 
the  system,  and  (2)  to  facilitate  user  interconnection  with  the  system  and  re-use  of  system  modules. 
For  each  purpose  each  element  of  the  system  has  potentially  a  hierarchy  of  documentation  detail 
starting  with  the  element's  objectives  and  proceeding  to  its  functional  description,  interface 
descriptions,  user  manuals,  and  maintenance  manuals. 

Through  the  preparation  of  supplemental  documentation,  the  system  will  be  described  to  sufficient 
detail  to  support  maintenance  and  to  support  a  general  level  of  foreseeable  enhancements.  An 
appraisal  process  to  be  completed  within  one  year,  will  determine  the  appropriate  level  of 
documoitation  for  each  system  element 

New  system  elemmits  will  be  added  through  DOs  for  experiments  and  system  enhancements.  The 
documentation  needed  to  maintain  and  integrate  the  new  system  dements  associated  with  each  such 
DO  will  be  developed  as  a  part  of  that  DO.  In  that  way  the  overall  ADST  documentation  wiU  be 
kept  up-to-date. 

In  some  cases,  a  new  DO  will  require  documentation  of  existing  system  elements  to  a  higher  level 
of  detail  than  included  in  the  overall  task  of  preparing  supplemental  documentation  as  part  of  the 
LSE.  In  those  cases,  that  additional  baseline-system  documentation  would  also  be  included  in  the 
effort  associated  with  the  DO. 
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5.2  Interface  Control 

LORAL  WDL  shall  operate  the  system  interface  control  program  through  the  CCB.  Systems 
Engineering  and  analysis  wiU  be  p^otmed  to  ensure  optimum  and  compatible  hardware/software, 
hardwaie/lurdware,  and  softwar^software  interfaces.  These  interfaces  will  be  documented  and 
controlled  by  Interface  Specifications  and  Interface  Control  Drawings  as  specified  and  funded  for 
any  particular  Delivery  Oixler  system. 
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6.0  Configoration  Traceability 


6.1  Nomenclature 

Tlw  process  of  nomenclature  assignment  and  the  requirements  for  titling  is  accomidished  dirough 
the  ADST  Oriando  technkal  library.  Procedures  for  dus  process  are  docunusmed  in  die  LC^Al 
Documentadtm  Plan  for  die  ADST  Program. 


6.2  Documentation  Numbering 

A  numbering  system  is  used  for  program  CDRL’s,  and  specifications.  These  numbers,  are 
assigired  by  the  Orlando  technical  library.  Procedures  for  this  process  are  documented  in  the 
L^Al  Documentadon  Plan  for  the  ADST  Program. 


6.3  Hardware  Identification 

A  comprehensive  list  of  all  hardware  identified  in  the  Loral  Software  Development  Facility  is 
currendy  being  maintained  by  the  LORAL  PMO.  The  ADST  System  Definition  Document  also 
provides  a  desOTption  of  thes^  systems. 


6.4  Software  Identification 

Software  is  identified  in  Version  Descriptions  documents,  the  SSL,  and  in  the  CM  Build  Load 
plans.  Refer  to  Sections  3  and  7  within  this  plan. 
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7.0  Connguration  Status  Accounting 

Configuration  Status  Accounting  will  be  the  means  through  which  control  and  tracking  of 
discrepancies  and  change  requests  affecting  O/CSCIs  are  reported  to  STRICOM,  and  engineering 
managers  concemed. 

The  Ctxifiguration  Status  Accounting  contains  a  Configuradtm  Identification  List,  DO  Status  Log, 
and  Version  Descriptions  Documents.  Whenever  a  status  change  occurs,  the  Configuration 
Identifications  Data  Base  is  updated  to  reflect  its  current  status.  Approved  DOs  to  the  product 
basdine  devdopmental  configurations  are  listed,  thus  providing  a  status  accounting  of  DOs  against 
eachCSCL 

This  data  is  kept  and  maintainpA  in  the  4D  SP/CR  data  base  server.  This  data  base  will  be  capdde 
of  providing  complete  configuradtHi  identification  and  status  of  each  Delivery  Order. 


7.1  Data  Bank  Description 


7.2  Data  Bank  Content 

The  sweep  does  not  support  a  formal  Data  Bank,  however.  Configuration  Management  will 
control  documents  in  boft  electronic  and  paper  form.  Systems  Requirements  Specification, 
System  Design  Specifications,  Source  Code,  I&T  Plan,  Test  Procedures,  Test  Reports,  and  other 
Documents  required  by  the  DO’s  will  be  controlled  on-line  or  in  file  cabinets,  book  shelves, 
notebooks,  etc.  A  tape  or  disk  backup  library  will  be  maintained  under  Configuration  Control  for 
all  software  packages 


7.3  Reporting 

Weekly  reviews  with  Configuration  Managemrat,  Process  Control,  SW  Engineering  Management, 
and  SQA  are  held  with  die  PEM  and  1^0.  Reporting  activity  status  will  be  as  follows: 

•  Weekly  activity  progress 

•  Monthly  WAD/^  reviews 

•  Weekly  mile^ne  reviews 

•  Periodic  Build  Plan  reviews 

•  Inputs  for  PMO/Customer  Briefs 


30 


ADST 

LORAL  WDL 


CoufiguEttioa  ManicBnieat  Plan 

1/ism 


8.0  Configuration  Management  Audits 

Formal  configuration  audits  and  reviews  for  the  ADST  program  are  not  a  requirement  of  this 
contract  However,  informal  technical  reviews  and  technical  audits  '.vill  be  part  of  die  surveillance 
throughout  die  life  cycle  of  die  project 

In  addition,  a  Software  Quality  Assurance  (SQA)  function  will  be  in  place  and  is  re^XHisible  for 
monittving  internal  crmfiguradon  management  procedures  diat  ensure  compliance  widi  the  SWCCP 
and  Cl^.  The  SQA  representative  provides  a  continuing  check  on  all  solvate  maintained  for  die 
ADST  program.  SQA  coonhnates  and  periodically  audits  the  configuration  maintenance  activities 
to  ensure  consistency  between  the  controlled  documentation,  soi^are,  and  database  elements 
comprising  each  DO  configuration.  SQA  works  with  CM  to  assure  that  baseline,  stiuus 
accounting,  library  and  chuige  control  procures  are  being  appropriately  presented  to  the  QC3. 
SQA  will  conduct  a  review  of  all  products  in  conjunction  with  a  major  software  baseline  capture 
and/or  release,  in  lieu  of  a  PCA/PC  A 
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9.0  SubcontractorA^endor  Control 

Within  the  context  of  the  Configuration  Management  Plan  the  rules  that  apply  to  the  Loral 
engineering  staff  will  also  i^ply  to  subcontractors.  In  particular,  tumovm’  of  sortware  developed 
on  the  ADST  contract  and  its  associated  Deliveiy  Or^rs  will  be  required  including  cold  start 
procedures,  data  tables,  and  documentatitm  as  specified  in  the  Statement  of  Woik.  Any  proprietary 
rights  must  be  identified  prior  to  issuing  the  subcontract  and  mutually  agreeable  between  Loral,  the 
subcontractor,  and  the  government 

The  software  provided  by  the  subcontractor  must  be  built  under  CM  control  and  issued  to  an 
Integration  and  Test  team  to  "sellofT  the  software.  This  is  advantageous  for  several  reasons. 
First  it  ensures  that  all  code  is  under  CM  control.  Second,  it  guarantees  that  what  is  being 
demonstrated  and  te^ed  is  traceable  to  the  source  code  under  control.  HnaUy,  liens  that  are  levied 
against  a  build  under  CM  control  can  be  woriced  off  in  an  orderly  maimer,  and  allow  sufficient 
regression  testing  to  take  place,  ensuring  that  a  "fix"  does  not  break  other  functionality.  Such 
traceabiliQr  and  accountability  provide  a  reusable  baseline  for  incremental  improvements  to  the  next 
delivery 
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APPENDIX  A.  ADST  TOP  LEVEL  PROGRAM  SCHEDULE 
Appendix  A  depicts  the  cunent  program  schedule  at  the  time  of  publication  of  this  document 
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APPENDIX  B.  CM  MILESTONE  SCHEDULE 

Appendix  B  dq>icts  die  current  CM  AcdviQr  schedule  at  the  time  of  fniblication  of  this  document 
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APPENDIX  C.  SOFTWARE  STANDARD  OPERATING  PROCEDURES 

(SSOP) 


.^pendix  C  defines  the  current  set  of  SSOP’s  as  referenced  in  the  Configuration  Management 
PlaiL  These  SSOP’s  will  be  updated  and  additional  SSOP’s  prepared,  as  required,  per  SSOP-OOl 
procedures. 
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SSOP  NO. 

SSOP-OOOl 

SSOP-0002 

SSOP-0003 

SSOP-0004 
(In  Process) 

SSOP-0005 

SSOP-0006 
(In  Process) 


TITLE _ 

SSOP  PURPOSE/PROCEDURE 
CONFIGURATION  CONTROL  BOARD  (CCB) 
CHARTER 

PROBLEM  REPORTING  PROCEDURE 
INTEGRATION  AND  TEST  PROCEDURE 

CODE  CHECKOUT/FTP 

PROBLEM  REPORTING  ACCOUNTING 
PROCEDURE 


SSOP-0007 

SSOP-0008 

SSOP-0009 

SSOP-0010 

SSOP-0011 

SSOP-0012 

SSOP-0013 

SSOP-0014 


CM  TURNOVER  PROCEDURE 
RCS  HEADER  COMMENT  STANDARDS 
DELIVERY  ORDER  RELEASE  KITS 
CM/SDF  BUILD  LOAD  DISTRIBUTIONS 
REVISION  CONTROL  SYSTEM  (RCS) 
VERSION  MASTER  SYSTEM 
CHANGE  CONTROL/BUILD  PROCEDURE 
FIELD  SUPPORT 
SP/CR  AUDIT  TRAILS 
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UTLE:  SSOPPURPOSE/PROCEDURE  SSOP  #0001 

DATE:  9/28/92 

AUTHOR:  K.  HUMBER  MOD: 


CCB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ PATE:. 


PURPOSE:  The  Advanced  Distributed  Simulation  Technology  (ADST)  Software  Standard 
Operming  Procedure  (SSOP)  serves  as  the  procedural  instruction  set  for  all  baseline  maintenance 
dements.  The  SSOP  master  file  will  be  maintained  by  the  Software  Configuration  Manager  and 
each  member  of  the  engineering  staff  shall  be  required  to  hold,  use,  and  keep  current  an  indvidual 
copy  of  the  SSOP. 

Any  member  of  the  engineering  maintenance  staff  may  submit  data  or  redlines  for  inclusion  in  the 
SSOP.  All  new  or  redUned  dam  shall  be  submitted  to  the  Software  Configuration  Manager  as  an 
enclosure  to  a  Software  Problem/Change  Rc^rt  (SP/CR).  The  SP/CR  wUl  then  be  submitted  to 
the  Software  Configuration  Review  Bo^  (SQtB)  for  review  and  approval  prior  to  its  inclusion  in 
the  SSOP. 

SSOP  inputs  shall  address  all  aspects  of  baseline  maintenance  to  include: 

Procedures  for  handling  software  changes 

Procedures  for  handling  documentation  changes 

Instructions  for  using  and  completing  basdine  maintenance  related  forms 

Procedures  for  maintaining  the  SSOP 

Procedures  for  the  SCRB 

Procedures  for  software  configuration  management 
Procedures  for  formal  testing 
Procedures  for  preparatitm  of  site  deliveries 
Procedures  for  int^acing  with  site  engineeting  personnel 


All  SSOP  inputs  shall  be  prepared  in  the  format  provided  in  this  document.  This  format  is 
available  from  the  Software  Configuration  Manager's  Public  Folder  and  utilizes  commercially 
available  Microsoft  Word  on  the  Ma^tosh  computer. 

SSOP  numbers  shall  be  assigned  by  the  SCRB.  All  new  inputs  shall  be  submitted  to  the  Software 
Configuration  Manager  with  the  SSOP  number  field  blank  and  shall  not  be  numbered  until 
approved  by  the  SCRB. 
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TITLE:  CONHOURATIONCONTOOL  BOARD  CHARTER  SSOP  #  0002 

DATE:  100/92 

AUTHOR:  K.  Humber  MOD: 


CCB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ DATE:. 


Oiarten  ADST  LORAL  WDL  CONHGURATTON  CONTROL  BOARD  (CCB) 

The  ADST  LORAL  WDL  CCB  responsibilities  are  to  assess,  review,  and  evaluate  the  necessity  for 
proposed  changes  to  {^proved  product  baselines.  Release  of  new  design(s),  and  changes  to 
Improved  baselines  require  approval  of  the  Loral  WDL  CCB.  The  CCB  is  chaired  by  the  Loral 
ADST  Program  Manager  and  is  composed  of  s^or  members  of  the  various  support  organizations 
including  Software  Configuration  Management.  The  CCB  will  meet  on  a  as  nmded  basis,  the 
frequency  and  time  of  meetings  to  be  determined  by  the  chairperson. 

The  CX3  will  mediate  conflicts  between  sites  doe  to  changes  (hardware,  firmware,  documentation, 
and  software  product  configuration  items);  categorize  and  prioritize  chwges  as  they  are  requested 
and  approved:  and  analyze  proposed  DO  updates  to  a  software  product  baseline.  Release  of 
specifications,  new  design(s),  and  changes  to  approved  baselines  require  approval  of  the  CCB. 

The  primary  reporting  mechanism  for  changes  to  the  BDS-D/DO  system  configurations  is  via  the 
Software  I^oblem/Change  Report.  The  SP/CR  provides  the  means  for  reporting  errors  in 
development,  test,  and  operatioiial  software  and/or  hardware.  An  SP/OR  is  completed  by  any  user 
or  developer  who  discovers  a  software  error,  or,  desires  a  modification  in  order  to  improve  system 
operational  efficiency.  The  SP/CR  provides  a  formal  means  for  recording  all  software  and 
hardware  faults  and  modification  requests.  Each  SP/C^  will  be  submitted  to  die  CCB  for  analysis. 
SP/CR’s  which  are  out  of  scope,  such  as  beyond  the  normal  schedule,  scope  of  current  activities, 
budget  or  enhancements/improvements  will  be  forwarded  to  the  LORAL  WDL  Program  office  for 
resolution. 

Data  submitted  to  the  CCB  shall  include,  but  not  be  limited  to,  the  following: 

-  Performance  problems  with  the  software  baseline 

-  Operational  discrepancies  with  the  software  baseline 

•  Prosed  or  direct  changes  to  the  software  baseline 

-  Proposed  or  directed  changes  to  identified  hardware 

-  New  or  revised  drawings 

-  New  or  revised  Software  Support  Operating  Procedures 

-  New  or  revised  build  procedures 

-  New  or  revised  command  files 

•  New  or  revised  data  formats 

-  New  or  revised  delivery  instructions 

-  New  or  revised  documentation  updates 

-  New  or  revis^  software  ronfiguration  management  policies/procedures 

Any  information  which  will  enhance  team  p^ormance  or  Ka-wliiw* *  fnaint<»nanri=». 
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The  ADST  CCB  shall  be  composed  of  the  following: 

CXS  Chairman  The  CCB  chairman  shall  preside  over  all  CCB  meetings.  In 

the  absence  of  the  CCB  chainnan,  the  vice  chairman  shall 
preside.  The  current  CCB  chairman  is  the  ADST  Program 
Manager,  Jerry  Novak 


CCB  Vice  Chairman  The  CCB  vice  chairman  will  coordinate  and  preside  over  all 

CCB  meeting  when  the  chairman  is  absent  The  current 
CCB  vice  chaitman  is  Rick  Bright 

Customer  Representative  The  customer  representative  will  act  as  the  liaison  between 

BDS-D  Sites,  and  the  LORAL  WDL  for  all  actions 
addressed  at  the  CCB.  The  current  customer  representative 
is  the  BDS*D  Manager,  Jim  Exter. 

CCB  Recorder  The  Software  Configuration  Manager  shall  serve  as  the 

permanent  CCB  recorder.  In  the  absence  of  the  CCB 
recorder,  an  alternate  recorder  shall  be  designated.  The 
current  CCB  recorder  is  Maria  Ipsaro. 

CCB  Orlando  Rq)resentative  The  Site  Coordinator  in  Orlando  shall  serve  as  the  liaison 

between  the  Orlando  Program  Office  and  the  WDL  CCB. 
The  current  Orlando  site  representative  is  Paul  Hinote. 

Site  CCB  Representatives  The  site  CCB  representatives  are  Randy  Kubik  from  Ft. 

Rucker  and  Jimmy  Adams  from  Ft  Knox. 

CCB  Permanent 

Members  All  Engineering  Technical  Leads,  Primary  Test  Engineer, 

and  the  {xogram  SQA  rqrresentative  ate  permanent  members 
of  the  AD^  CCB.  Attendance  for  permanent  members  is 
mandatory  at  any  scheduled  CCB. 

CCB  Member 

At-Large  CCB  membership  shall  include  all  engineers  assigned  to  the 

ADST  maintetumce  staff.  Attendance  by  non-permanent 
members  shall  be  based  upon  the  agenda  and/or  the  need  for 
outside  technical  support 

All  data  submitted  to  the  CCB  shall  be  in  the  form  of  a  Software  Problem/Change  Request 
(SP/CR)  form.  SP/CR’s  written  at  the  sites  will  be  reported  to  the  designated  site  coordinator  and 
then  to  the  CCB. 

The  basic  flow  of  SP/CR  data  through  the  CCB  is  as  follows: 
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Receipt  of  SP/CR  All  incoming  SP/CRs  are  entered  into  the  SP/CR  data  base 

■  by  the  submittor.  An  E-mail  message  is  sent  to  die  Software 

P  Configuration  Manager/CCB  Recorder,  so  the  SP/CR  is 

added  to  the  agenda  for  the  next  CCB. 

■  CCB  Review  of  New 

~  SP/CR  All  new  SP/CRs  will  initially  be  assigned  to  a  responsible 

engineer  for  analysis.  The  engineer  shall  prepare  a  written 

■  proposed  solution/analysis  which  provides  information 

I  concerning  the  scope  and  comptexity  of  the  required  change. 

Once  the  proposed  solution  is  accepted  by  the  CCB,  the 

■  assignee  can  begin  the  fix. 

Receipt  of  CCB 

_  Direction  Upon  receipt  of  CCB  direction,  the  SP/CR  shall  be  placed  in 

I  the  status  designated  by  the  CCB.  Refer  to  &e  CCB 

i  DISPOSITION  INSTRUCTIONS  of  this  SSOP  for 

information  concerning  actions  to  be  taken  in  response  to 

■  CCB  direction. 

~  The  following  defines  disposition  instructions  in  response  to  actions  assigned  by  either  the  CCB: 

■  IMPLEMENT  Responsible  engineer  will  be  assigned  to  implement  the 

^  approved  wo^lan.  The  engineer  shall  prepare  required 

co^changes  in  the  development  environment,  shall  conduct 
I  informal  unit  testing  to  ensure  the  change  is  error  free,  and 

if  shall  redline  or  draft  required  documentation  changes 

associated  with  the  change.  Upon  completion  of  all  required 

■  actions,  the  responsible  engineer  shall  submit  to  the  CCB 

I  listings  of  all  new/modified  code,  copies  of  all  new/redlined 

^  documentation,  listings  of  all  new/modified  command  files, 

.  utilities,  build  procedures,  or  othm’  files  associated  with  the 

I  formal  baseline.  Specific  due  dates  will  be  assigned  for 

^  implementaticm. 

■  DEFER  SP/CRs  may  be  assigned  to  deferred  status  if  the  CCB 

jP  determines  that  the  proposed  change  is  iniqipropriate  for 

implementation  at  this  time.  Deferred  SP/CRs  are  not 

■  reviewed  at  weekly  CCB  meetings  but  may  be  reopened  at  a 

■  future  time.  Due  dates  for  defend  SP/C^  shall  be  INDEF. 

BASELINE  The  Software  Confiiguration  Manager  shall  update  the 

I  appropriate  software  or  documentation  baseline  with  the 

changes  submitted  by  the  responsible  engineer.  Upon 
completion  of  the  baselining  process,  the  Software 

■  Configuration  Manager  shall  prepare  an  up^ted  build  of  all 

P  ^fect^  software  and  shall  notify  the  CCB  that  the  software 

is  available  for  informal  system  test  Specific  due  dates  shall 

■  be  assigned  to  SP/CRs  assigned  for  baselinimg. 
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TEST  Tbe  iiidq)endent  software  system  test  engineer  shaU  prepare 

test  procaines  and  conduct  required  system  testing  of  Ute 
modified  software  baseline.  Additionally,  the  software 
system  test  engineer  shall  perform  applicable  regressitm 
testing  to  ensure  the  change  has  not  affected  otho’  software 
functionality.  Upon  completion  of  informal  system  testing, 
the  software  system  test  mgineer  shall  inform  the  CX^B  th^ 
the  software  has  been  successfully  tested  and  sludl  submit 
formal  test  procedures  to  the  CX!B,  if  applicable.  Specific 
due  dates  sh^  be  assigned  to  SP/CRs  aosignad  for  test 

CX.OSE  For  SP/CRs,  closure  shall  be  authorized  upon  cmnpletion  of 

all  implementation  and  test  activities  and  acceptance  by  the 
CCB. 

WITHDRAWN  This  status  shall  be  assigned  to  SP/CRs  which  the  originator 

has  elected  to  remove  from  the  formal  processing  cycle,  b 
most  cases,  SP/CRs  will  only  be  withdrawn  when  it  has 
been  determined  that  no  problem  actually  exists,  or  that  there 
is  a  solution  to  this  problem  available  within  the  current 
baseline. 

ANALYSIS  The  basic  actions  to  be  taken  during  analysis  are  defmed  on 

the  pages  of  this  SSOP  titled  CCB  SP/CR  PROCESSING. 
It  should  be  noted  that  major  system  enhancements  may 
result  in  a  workplan  which  recommends  generation  of  a 
formal  ECP  for  submission  to  the  ADST  program  office.  In 
most  cases,  such  recommendations  shall  be  limited  to 
changes  or  enhancements  which  are  of  such  size  or 
complexity  that  they  cannot  be  completed  with  the  current 
rdease  schedule  or  costing. 

The  CCB  shall  assign  priorities  to  all  SP/CRs.  The  priority  assigned  is  used  to  convey  the  urgency 
associated  with  the  change.  Authors  should  recommend  a  priority  when  drafting  SP/CRs. 
Responsible  engineers  should  ensure  higher  priority  SP/CRs  are  worked  before  lower  priority 
SP/CRs. 

IMMEDIATE  This  priority  is  reserved  for  problems  which  result  in  one  of 

the  following  conditions: 

Entire  system  is  rendered  inoperable 
Major  capability  is  rendered  inoperable 
Syston  is  experiencing  major  periods  of  downtime 
System  is  unable  to  pe^orm  b^c  operational  capability 

The  CCB  recorder  shall  call  an  immediate  CCB  to 
disposition  the  SP/CR  and  correction  is  expected  to  occur 
within  24-48  hours.  If  at  all  {wssible,  coordmation  with  site 
petsoimel  shall  be  handled  via  phone  and/or  fax.  Once  the 
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URGENT 


ROUTINE 


ENHANCEMENT 


immediate  problem  has  been  solved,  the  SP/CR  shall  be 
reassigned  priority  URGENT. 

This  priority  is  reserved  for  SP/CRs  which  are 
recommended  or  directed  for  implementation  as  part  of  the 
next  scheduled  software  release.  SP/CRs  in  this  priority 
reflect  problems  which  impact  daily  operations  but  vt^h  do 
not  require  immediate  correction.  In  most  cases,  such 
SP/CRs  will  address  issues  such  as  minor  processing 
discrepancies  which  can  be  accommodated  with 
workarounds,  minor  enhancements  to  existing  capabilities, 
or  discrroancies  which  can  wait  for  the  next  scheduled 
release.  SP/CRs  in  this  priority  will  normally  be  resolved  as 
quickly  as  pebble  and  will  te  closed  upon  completion  of 
requir^  actitHis. 

This  priority  is  reserved  for  SP/CRs  which  involve 
recommended  or  direct  changes  which  have  minimal 
operational  impact  In  this  case,  implementation  is  desired, 
but  can  wait  for  a  release  which  can  accommodate  lower 
level  priority  problems. 

This  priority  is  reserved  for  recommended  enhancements 
which  are  not  essential  to  operational  system  performance. 
Such  enhancements  will  only  be  implemented  when  directed 
by  the  ADST  Program  Office. 
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TtlLE:  PROBLEM  REPORUNOPRCXIEDURE  SSQP  #  0003 

DATR*  l(y3/92 

AUTHOR:  K.  Humber  MOD: 


QCE  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ ^DATE: 


This  procedure  addresses  the  SP/CR  form  and  provides  detailed  instructions  concerning 
completion  of  all  q>plicable  data.  The  ADST  SP/CR  Database  System  is  a  multi-user  Software 
Problem  Reporting  application  using  the  4th  Dimension  DBMS.  It  was  designed  to  addr^  the 
need  for  a  low  cost  Mi^tosh  based  SP/CR  system. 

A  Quick  &  Dirty  User’s  Manual  is  attached  for  your  reference  in  the  use  of  die  tool  and  the  SP/CR 
screens.  The  manual  includes  field  name  and  descriptions,  pull-down  menu  selections  and 
explanations.  Also  attached  is  a  copy  of  the  SP/^  front  page  form. 

User’s  are  placed  into  one  of  four  functional  groups:  Administration,  Approver,  Assignee,  and 
CM.  These  groups  have  distinct  menu  bars  wfaikh  define  the  limit  of  that  group's  access  to  the  data 
within  the  SP/CR  system  and  parallels  the  functions  to  be  peifoimed  by  the  group. 

Hie  diagram  below  d^icts  all  SP/CR  menus  and  menu  items;  however,  die  exact  menus  appearing 
during  an  SP/CR  session  depend  on  the  user's  group  type.  Refer  to  the  Quick  &  Duty  User’s 
Manual  for  details  on  the  fun^ons  (tf  each  type  of  user. 
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For  further  informadon.  please  see  Maria  Ipsaro  or  Pete  Peterson  from  the  ADST  Configuration 
Management  team.  They  will  have  “Administrator'’  accounts  in  order  to  add  new  accounts  and 
maintain  existing  accounts. 
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TTILE:  CX)DE  CHECK  IN/OUT  USING  FTP  SSOP  0005 

DATE:  20  October  1992 

AUTHOR:  ME.  Ipsaro  MOD: 


CCB  PROCESS  CONTROL 

APPROVAL: _  DATE: _ APPROVAL _ ATE:. 


PURPOSE:  Identify  a  procedure  for  checking  code  in/out  firtun  the  CM  environment  using  FTP. 
These  steps  must  be  foUowed  to  ensure  inte^ty  of  the  CM  baseline  and  traceablity  of  the 
software. 

The  most  cunentversitm  of  eadi  file  resides  on  die  CM  disk  in  the  re^)ective  directory  tree.  Read* 
only  access  is  granted  to  all  files  under  CM  control.  Prior  to  making  any  modifications  and  in 
order  to  obtain  the  most  correct  version  of  a  file,  all  files  must  first  be  copied  from  the  CM 
environment  into  an  engineer's  development  directory  using  "cp"  or  "FTP".  Revision  Ctmtrol 
System  (RCS)  is  the  code  management  tool  used  by  CM  to  store  and  maintain  all  released  versions 
of  files  and  baselines. 

I.  COPYING  THE  CURRENT  VERSION  OF  A  FILE  LOCALLY 

1 .  Login  into  a  SUN  using  your  account  name  and  password. 

2.  Set  your  default  to  your  working  diiectmy. 

3.  Enter  the  command  to  copy  the  dedgnatedfilefs): 

cp  /aS/adst-cm/XXXAfilenameCs) . 

II.  COPYING  MODIFIED  FILE(S)  TO  THE  CM  TURNOVER  DIRECTORY 
USING  FTP 

1 .  Log  into  FTP  using  the  account  name  and  password. 

2.  Set  your  default  dirotory  to  die  location  of  the  modified  file(s)  for  turnover. 

3.  Enter  the  COTimand  to  copy  the  modified  file(s)  on  to  the  CM  di^: 

put  filename(s)  /a3/tumovei/XXX 

3.  Once  the  file(s)  have  been  copied  to  the  turnover  directory  logout  of  FTP. 

4.  Ixigin  using  TELNET  and  set  default  to  the  turnover  directory  and  reset  file 
privileges.  This  permits  the  owner  to  have  read,  write,  and  execute  privileges, 
vkrith  group  and  woild  having  no  privileges. 

cd  /a3/tumover/XXX 
chmod  700  filename(s) 

5.  Send  a  mail  message  to  CM  notifying  them  of  code  turnover. 
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TTILE: 

CM  Tdmover  Procedure 

SSOP  0007 

DATE: 

20  October  1992 

AUTHOR: 

ME.  Ipsaro 

MOD: 

CTB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ ^DATC: 


PURPOSE:  Identify  a  fonnal  method  of  tunung  modified  code  over  for  incorporation  into  the 
CM  baseline.  This  procedure  creates  an  organized  approach  for  transitioning  mo^ed  code  fnnn 
an  engineer's  workspace  to  a  temporary  location  for  capture  and  placement  into  the  controlled 
baseline  by  CM. 

Prior  to  code  turnover,  the  responsible  engineer  must  perform  a  successful  software  build  in  the 
thdr  development  environment  The  engineer  must  alw  be  able  to  load  and  demo  tire  application 
on  the  target  machine  (if  necessary). 

For  initial  turnover  of  code,  the  engirreer  must  turnover  over  all  source  code  required  to  build  the 
application  (.c,  Ji,  makefiles,  .txt  .def,  etc.,)  and  run  the  application  (.d,  .p,  .com,  etc.,),.  Test 
plans,  test  scripts  and  test  data  is  an  tntegrd  p^  of  the  initial  turnover.  If  this  data  exists  at  initial 
turnover  or  if  is  created  subsequently,  it  is  essential  that  it  is  turned  over  to  CM  for  control. 
Engiireers  ate  not  requited  to  turnover  any  extnureous  files  such  as  object  files  and  libraries,  .old, 
.save,  and  executable  files.  These  file  wfll  not  be  accepted  as  pan  of  the  initial  turnover.  CM 

reserves  the  right  to  refuse  the  turnover  if  it  ccmtains  extraneous  (garbi^e)  files.  CM  will  insen  the 
requited  Revision  Control  System  (RCS)  header  information  upon  initial  turnover  for  the  ".c", 
".h",  and  "makefiles".  At  this  time,  RC^  header  infimnation  is  not  requited  on  any  other  file  type. 
The  engineer  must  follow  the  Prologue  &  RCS  Header  Comment  Block  Standard  set  forth  in 
SSOP  ()008  for  trew  files  and  modified  files. 

Software  build  and  installation  procedures  ate  required  to  be  tunred  over  with  the  initial  turnover  of 
code.  Updates  to  these  procures  will  be  turrod  over  by  the  responsible  engineer  as  necessary. 
The  build  procedures  must  idmitify  the  build  steps  r^uited  and  the  executable  file(s)  that  wiU  bt 
produced  as  a  result  of  a  successful  compilation  and  Imk. 

Code  is  ready  for  turnover  upon  successful  completion  a  development  build  and  unit  testing  of  aU 
changes.  A  turnover  directory  is  identified  for  each  DO.  This  directory  is  open  for  read,  write, 
and  delete  acc^  by  engineers.  The  responsible  engineer  will  copy  the  modified  source  code 
and/or  applicatiori  ffles  into  the  designated  turnover  location  on  the  CM  disk.  (For  example,  the 
RWA  code  is  copied  to  /a3/tutnover^WA).  Tire  responsible  engineer  must  notify  CM  requesting 
a  build  of  the  initial  turnover  or  the  latest  changes  to  the  baseline.  For  each  turnover,  the  engineer 
must  prepare  and  delivn'  a  list  of  files  being  turned  over  to  CM.  (A  sample  turnover  ^eet  is 
attached  to  this  SSOP).  If  the  list  of  files  is  extensive,  a  directory  listing  may  substitute  the 
turnover  form  ^  long  as  die  director  paA  is  i»ovided  for  each  file,  the  SP/CR  number  and  the  DO 
name  are  specified,  and  new  files  identified.  This  turnover  list  documents  what  is  being  turned 
over  for  the  build  and  serves  as  a  self  check  for  the  engineer  and  CM.  The  turnover  directory  will 
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be  Cf^ied  to  the  CM  enviromnent  fw  incorporatioii  into  RCS  and  the  contents  of  the  turnover 
direct^  deleted. 

For  incremental  tumovm  (subsequent  builds  after  initial  turnover),  engineers  must  generate  a 
Sttftware  Problem/Change  Report  (SP/CR)  if  a  file  modification  is  required.  (Refer  to  SSOP  (X)03 
for  q)ecific  instructions  on  the  use  of  SP/CRs).  The  modified  file(s)  must  be  documented  with  die 
sq[>propriate  SP/CR  information  in  the  header  comment  block  and  audit  trailed  in  the  body  of  the 
co^.  (Refer  to  SSOP  (X)14  for  informatimi  on  audit  trails). 

The  latest  controlled  version  of  the  CM  baseline  is  located  on  /aS/adst-cm/directory.  If  a 
modihcation  to  a  file  is  required,  engineers  must  obtain  the  latest  version  from  the  CM  baseline. 
Rles  on  the  CM  disk  are  open  for  read-only  access  and  can  be  copied  to  an  engineer's  workspace 
for  mndificatinn.  The  location  die  CM  baseline  for  each  DO  is  m  the  /a3/adst-cm  directory  tree. 
If  an  engineer  wishes  to  review  and/or  modify  a  previous  version  of  a  file(s)  that  is  under  CM 
control,  the  engineer  must  make  a  request  from  CM.  The  CM  engineer  wiU  ch^k  out  a  read-only 
copy  of  the  previous  version  of  a  file(s)  and  copy  it  to  die  engineer's  workspace.  (This  procedure 
is  o^y  temporary  until  a  development  environment  is  establi^ed  for  each  DO.  A  copy  of  the  CM 
environment  will  be  created  for  software  engineering.  It  will  contain  the  entire  diret^iy  tree  and 
the  RCS  subdirectories.  Ihis  is  die  engineering  development  environment  Engineers  will  manage 
and  control  their  ^velopment  changes.  At  anytime  in  the  development  process  they  can  checkout 
review  and/or  modify  previous  versions  of  a  fi)e(s)).  All  changes  will  be  submitted  back  to  the 
central  Software  Support  library  (SSL)  baseline. 
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AOST  SOFTWARE  TURNOVER  FORM 


LORAL  g 

SfTE  0 _ _ 
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Daivwy  ORl«r(DO): 


LM  ol  updated  Mm 


Otoaetory  Path  Namai 
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TTTLE:  Prologue  &  RCS  Header  Comment  Block  Standard  SSOP  0008 

DAIE:  1  October  1992 

AUTHOR:  M.  E.  Ipsaro  MOD:  15  Januaiy  1993 


CCB  PROCESS  CONTROL 

APPROVAL: _ DATE: _ APPROVAL _ ^D  ATE:. 


PURPOSE:  The  purpose  of  this  SSOP  is  to  provide  guidance  and  standards  to  produce  source  Hie 
prologues;  and  guidance  and  standards  to  prepare  your  file  for  Revision  Control  System  (RCS) 
control. 

PROLOGUE: 


Source  lines  shall  be  no  longer  than  78  characters. 

Each  source  file  must  contain  a  prologue  in  the  following  format* * 


*  File  Name: 

*  System: 

*  Project: 

*  De^ption: 

<)> 


Version 


D?.tB  Author 


Title 


SP/CR  No. 


*  Target  Platform: 

*  Special  Hardware: 

*  OS  &  Version: 

*  Cmnpiler  &  Version: 
Makefile/Proj^ 

*  Compiler  Options: 
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’^Reference: 

* 

*  Description: 

*Ii^)uts: 

* 

C)uQ)uts: 

* 

/4i4ii»«4i4ii»i^4i4i«4i4i4i4i4ii»*4i**4i4i*4i*i»*4>4i*4>*4i4i4i4ii»*4i*4i4i4i«**4i4i«4i**4i4>4i4> 

* 

*  SP/CR  No.  Description  of  Modification 

4i 


*4i4i«i»4i^i»4i  4141 4141411^  4ii^4i«4i4i««4i4i4i4i4i*«4ii»«i^4ii»]^i^**4i*4i  4141^^41 414141414141414141^ 


RCS  HEADERS: 

The  version  control  tool  that  will  be  utilized  on  the  program  for  tracking  code  modifications  is 
Revision  Control  System  (RCS).  RCS  requires  that  header  information  be  inse^rted  before  the 
prologue  at  the  top  of  each  ".c",  ".h".  and  Makefile .  An  example  of  each  is  listed  below. 

Example  of  RCS  header  information  for  a  .c  file: 

/*  $Header$  ♦/ 
t* 

♦$Log$ 

♦/ 

static  char  RCS_IDn  ~  "$Headers$"; 

Example  of  RCS  header  information  for  a  .h  file: 

/*$Headei$*/ 

/* 

♦$Log$ 

*! 


Example  of  RCTS  header  information  for  a  Makefile: 
#$Header$ 

#$Log$ 


008 
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TmE: 

Delivery  Order  Release  Kit 

SSOP  #0009 

DATE: 

26  October  1992 

AUTHOR: 

K.  L.  Humber 

MOD:  2  December  1992 

CCB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ ATE:. 


PURPOSE:  This  SSOP  outlines  the  elements  required  to  support  a  Delivery  Order  Software 
release  as  required  by  the  sponsoring  organization.  The  elements  required  for  a  Delivery  Order 
package  may  vary  depending  on  the  release  r^uirements.  Each  kit  will  be  available  for  general 
release  unless  specified  by  the  customer  for  limited  release. 

Each  Release  Kit  will  be  comprised  of  the  following  List  of  items: 

1 .  Delivery  of  a  Version  Description  Document  depicting  the  entire  software  baseline  ciq)ture 
(or  delta  from  the  previous  baseline  build),  to  include  new.  deleted,  and  updated  modules 
and  directory  structure.  The  format  for  the  VDD  will  adhere  to  DI-MCCR-80013A,  CDRL 
requirement  for  the  SW  Support  CCP.  The  VDD  will  be  will  be  generated  on  the  MAC  in 
Microsoft  WORD  and  distributed  to  the  sites  on  a  floppy  disk  dong  with  one  hardcopy. 
The  VDD  will  include,  but  riot  limited  to: 

a.  System  Overview 

b .  Inventory  of  Materials  Release 

c.  Inventory  of  CSCI  contents: 

provide  a  snapshot  of  the  RCS  (current  version)  source  libraries  at  the  time  the 
build  'Tieeze”  is  created.  Review  RCS  librarie^structures  for  adherence  to  CM 
practices,  policies,  and  procedures. 

d.  Changes  Installed: 

iden^cation  of  SP/CR*s  that  are  associated  with  this  release  (open,  closed, 
pending). 

e.  Build  and  Distribution  Instructions. 

f .  Regression  Test  Results.  Provide  tools  to  support  any  necessary  on-si.te  regression 
^ting,  if  applicable 

g.  interface  CompatibiliQr 

h.  Ad^tation  data: 

Unique  to  site  data,  if  applicable. 

j.  Summary  of  changes: 

provide  softcopy  SP/CR’s  and  minutes  from  the  CCB  for  review 

k.  Release  Notes: 

installation  instructions.  Depict  notes/differences/compatibility  since  the  last 
release. 

l.  Identification  of  known  problems  and/or  discrepancies. 

m .  Identification  of  the  hardware  configuration  required  by  a  software  release. 
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n.  Reference  to  the  Acceptance  Test  Plan  for  use  to  recertify  a  configuration  has  been 
restored  to  its  "baseline"  configuration.  (Recertification  may  be  accomplished  by 
rerunning  an  acceptance  test). 

2.  Coldstart  Procedures.  A  written  list  of  instructions  that  allow  construction  of  executable 
images  based  on  source  code  installed  on  a  system  support  configuration.  This  includes 
proc^ures  required  to  move  and  install  the  compiled/linked  executable  image(s)  to  a  target 
configuration.  The  procedures  include  startup,  ^utdown,  operational  modes  (as  required), 
and  installation  and  distribution  instrucdcms,  interaction  with  other  simulators  and  hardware 
compatibUiQ'  notes  (as  applicable). 

The  Coldstart  Procedures  will  contain  the  following  statement  regarding  the  certification  of 
the  software  as  being  free  from  security  threats  to  the  best  of  our  knowledge:  "I  tnamg  of 
CM  Manager)  on  this  (date)  hereby  certify  that  the  software  release  (name  of  software 
release)  has  been  built  from  a  limit^  access,  controlled  baseline.  This  software  is,  to  the 
best  of  my  knowledge,  free  of  malicious  code  intended  to  subvert  its  operation." 

3.  Identification  of  command  files  required  for  the  build  configuration  setup,  and  distribution 
process.  Identification  of  data  files,  data  bases,  etc.,  required  to  bring  up  the  system. 

4.  English  narrative  synopsis  of  functionality  of  the  released  system. 

5 .  Documentation  updates,  including  drawing  configuration  changes,  as  ^plicable. 

6.  Standard  header  information  for  ease  of  tape  identification,  to  include  the  following 
information: 

(1)  Project  Title  and  Government  Contract  Number/Date 

(2)  Title  of  software  program 

(3)  Date  and  release  number  of  software 

(4)  Sponsoring  Agency 

(5)  Security  Clas^cation 

(6)  Name,  address  (office  symbol)  and  phone  number  of  agency  who  can  release 
software  for  use  by  anoth^  agency/contractor 

(7)  Name  and  phone  number  of  contractor  POC  for  release 

Some  Delivery  Orders  (Le.,  VIDS)  also  require  the  following  release  Idt  documentation: 

1 .  Software  Maintenance  Manual  (similar  to  the  VDD  format).  This  manual  will  focus  on 
describing  details  of  how  to  perform  a  build,  change  control,  and  description  of  supporting 
docummtation.  The  elraients  that  comprise  the  Software  Maintenance  Manual  ate: 

a.  Delivery  Order  Overview  (architectural,  software  and  hardware,  interfaces) 

b.  Hardware/Software  Descriptions 

c.  CM  cold  start  procedures,  distribution  and  installation  procedures  of  a  build. 

d .  CM  change  control  procedures  and  reporting  of  problems. 


1/19/93 


SSOP  #0009 


C-19 


ADST 

SOFTWARE  STANDARD  OPERATING  PROCEDURE 


e.  Documentation  Cross  References  (functional  description,  test  plan, 

operator’s/user’s  manual) 

Opeiator’s^ser’s  Manual  comprised  of  die  following: 

a.  Operations  Ctmcqit 

b.  Operations  (startup,  shutdown,  operational  modes,  interaction  with  other 

simuUuors). 
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ITILE:  CM^F  BUILD  LOAD  PRCXEDURES  SSOP  #  0010 

DATE:  \Qiy9i 

AUTHOR:  B.  MOHNING  MOD: 


CCB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ PATE:. 


PURPOSE:  The  Configuration  Management-Software  Development  Facility  Build  Load 
Distributions  Procedure  is  the  instruction  set  for  downloading  builds  from  the  CM  envirorunent  to 
the  development  environmenL 

1.  Back  up  any  files  on  the  target  machine  that  you  may  overwrite.  A  list  of  files  to  be 
installed  will  be  kept  in  the  directory  containing  the  build. 

2.  From  the  CM  account,  change  directory  to  the  build  you  want  to  download.  All  build 
packages  ate  stored  (xi  /aS/BlMD/TX)  Name**  (Le.  /a3^UlLD/RWA).  The  files  you  need 
will  be  stored  in  tar  format  and  called  “DO  name*’.“version**.tar.  FTP  down  to  die  target 
machine.  Do  this  from  the  command  prompt  by  typing  ftp  “target  machme  name**  and 
pressing  reUirn.  FTP  will  then  prompt  vou  for  vour  password  on  that  machine.  After  you 
have  entered  your  password,  you  will  get  the  ftp>  prompt  Now  change  directory  to  where 
you  want  to  load  the  tatfile.  Once  ther^  t^  put  “padi^e  name**  and  hit  return.  Your  tar 
file  will  now  be  loaded  on  the  target  machine^When  the  prompt  comes  back,  type  bye 
and  press  return.  This  will  take  you  out  of  FTP  and  return  you  to  your  local  machine. 

3.  Login  on  the  target  machine.  You  can  do  this  by  using  either  riogin  or  telnet  To  use 
rlogin,  type  riogin  “machinename**  and  press  return.  To  use  telnet  type  telnet 
“machinmuune**  and  press  retunt  In  either  case,  you  will  prompted  for  a  password,  enter 
your  password  and  hit  return.  When  you  get  logged  on,  cd  to  the  directory  diat  contains 
the  tar  file  you  just  downloaded  in  step  2.  Once  there,  ^pe  tar  xvf*‘tatfilename**  and  press 
return.  You  are  now  ready  to  run  the  new  installation. 
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TTTLE:  Revisira  Control  System 

DATE:  1  December  1992 

AUTHOR:  ME.  Ipsaro 

MOD: 

SSOP  0011 

CCB 

APPROVAL:  DATE: 

PROCESS  CONTROL 
APPROVAL 

DATE: 

PURPOSE:  Identify  a  version  control  tool  which  tracks  many  versions  and  configurations  of  the 
software  system  during  program  development  and  maintenance.  Revision  Control  System  (RCS) 
ensures  that  each  sofiw^  configuratitm  is  controlled  in  a  manner  which  pr^rves  accuracy  and 
maintains  up-to-date  infoimation.  RCS  is  a  software  tool  vdiich  manages  revisions  to  source  files 
and  provid^  a  method  for  storing  and  tracking  changes  to  those  files.  It  automates  the  storing, 
retrieval,  identification  and  trac^ility  of  revisions,  and  it  provides  selection  c^abilities  for 
composing  software  configurations. 

All  baselined  files  are  located  in  RCS  subdirectories  for  each  directory  in  the  directory  tree.  All 
source  files  required  to  build  the  implication,  run  the  application,  test  scripts,  test  data,  and  tools 
are  contained  in  RCS.  Hies  turned  over  by  tlm  engineer  for  control  are  checked  into  RCS  by  the 
CM  engineer.  The  CM  engineer  ensures  t^  the  iqrprtmriate  RCS  header  information  (see  SSOP 
(XX)8)  is  contained  in  the  "*.c*.  "*.h*,  and  "make"  files  before  placed  into  RCS.  AU  the  files 
will  then  be  checked  into  RCS  using  the  check  in  command  with  an  aj^ropiiate  message  denoting 
the  description  and/or  reason  for  the  checkin  and/or  modification.  A  read-only  copy  will  be 
retained  in  the  directtny  tree.  Fw  example; 

ei  •«  -rn'InUial  Turnover*  ••• 

The  checkout  command  extracts  the  latest  veisimi  from  RCS  and  places  it  in  the  woridng  directory. 
The  file  can  be  edited,  and,  when  finished,  checked  back  into  RCS.  This  command  chedcs  out  a 
file  from  RCS  widi  a  lock  to  prevent  accidatal  overwrites.  For  muunple; 

CO  -/  -rn'Initial  Turnover*  filename 

A  previous  version  can  be  checked  out  for  read  only,  by  using  tb^  r  option.  For  example; 
eo  -rl.l  -u  <‘m*work  in  progress*  filename 

A  ctxnplete  history  of  changes  is  accumulated  as  log  messages  that  are  requested  at  check  itL  To 
view  die  history  of  changes  to  a  RCS  subdire^oty  rater  the  following  command: 

rlog  RCS/* 

To  view  the  history  of  changes  to  a  particular  fife,  rater  the  following  command: 
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fiof  JtUmaMu 

The  icsdiff  command  compares  revisions  of  a  files  contained  in  RCS.  The  following  command  is 
used  to  run  differences  between  revision  1.1  and  1.2: 

rcMdiff  •rl.l  •rl.2  filename 

Hie  icsfieezB  command  records  a  software  configuration.  Rcsfreeze  assigns  a  symbolic  number  to 
a  given  revision  in  all  RCS  files  thus  taking  a  snaj^ot  of  all  the  files  at  a  fixed  point  in  time. 

Listed  in  this  SSCX*  are  a  few  examples  of  the  RCS  commands  that  are  used  to  checkin,  checkout, 
view  a  history  of  changes  to  files,  and  run  differences.  For  more  information  on  RCS  and  its 
options,  refer  to  the  document  RCS  •  A  System  for  Version  Control  by  Walter  F.  Hchy, 
di^  3  January  1S)91  and  the  man  pages  on  the  UNIX  system. 
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TITLE:  Version  Master  System  SSOP  #  0012 

DATE:  14  January  1993 

AUlHCm:  M.  Ipsaro  MOD: 


CCB  PROCESS  CONTROL 

APHIOVAL: _ ^DATE: _ APPROVAL _ DATE: 


PURPOSE:  To  describe  the  Version  Master  tool  used  on  the  Macintosh  for  controlling  and 
managing  any  type  of  Macintosh  files. 

Version  Master  is  a  document  version  managemrat  and  control  product  for  the  Apple  Macintosh. 
Version  Master  manages  the  creation  and  modification  of  Hies  on  a  Macintosh.  It  stores  all 
versions  of  a  file  in  a  single  icon,  and  it  allows  a  user  to  aimotate  each  new  version  providing 
traceability  to  when  and  why  certain  changes  were  made.  Version  Master  stores  documents  in  a 
central  database  within  a  Project  folder.  Dwuments  are  transfenn»l  to  and  fircan  ("checked  in"  and 
"checked  out")  of  the  Version  Master  database  by  using  the  Version  Master  DA  and  by  using  the 
Version  Master  extension  to  die  standard  (^len  dialog  of  most  triplications. 

Version  Master  helps  users  coordimite  changes  when  woridng  together  on  a  product  or  working 
alone.  It  provides  formation  about  document  changes  such  as:  who  has  modified  a  particular 
document,  what  changes  have  been  made,  who  is  currently  modifying  the  document,  and  the 
complete  revision  history.  Users  are  able  to  work  with  the  latest  versions  of  documents  and  can 
easily  integrate  changes  with  those  of  other  users.  Eariier  versions  are  archived  for  easy  retrieval 

An  important  feature  of  Version  Master  is  document  modification  interlocking.  A  user  cannot 
modify  a  document  if  another  user  is  modifying  the  same  document  Ihis  is  especiaUy  important 
in  a  muld-user  environment  where  many  users  share  the  samft  documents. 
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TTTLE:  CHANGE  CXWTROUBUILD  PROCEDURE  SSOP  #  0013 

FIELD  SUPPORT 

DATE:  l(yi6/92 

AUTHOR:  K.  HUMBER  MOD: 


CCB  PROCESS  CONTROL 

APPROVAL: _ ^DATE: _ APPROVAL _ ^DATE: _ 


PURPOSE:  This  procedure  and  diagram  depict  the  process  for  ADST  Site  Software  Engineers 
who  require  the  use  of  the  LORAL  WDL  Software  Development  Facility  (SDF)  for  debugging 
and  building  software.  In  the  event  the  site  development  configmtion  does  not  provide  the  correct 
environment,  an  engineer  can  perform  their  tasks  using  the  equipment  in  the  SDF  by  logging  into 
the  EI^  network,  lowing  thra  to  log  on  remotely,  make  changes,  initiate  a  build,  and  tranter  it 
over  the  link.  The  coordituition  of  this  process  will  be  in  cooperation  with  the  LORAL  WDL  CM 
staff  and  the  LORAL  WDL  SQA  sttdf.  All  known  problems  during  I&T  will  be  documented  on 
the  Problem  Repotting  Form  as  described  in  SSOP-0003,  and  processed  through  the 
Configuration  Control  Board. 


•  CM 


1/19/93 


SSOP  #0013 


C-25 


ADST 

SOFTWARE  SUPPORT  OPERATING  PROCEDURE 


irTLE:  SP/CR  Audit  Trails  SSOP  0014 

DATE:  2  December  1992 

AUTHOR:  ME.  Ipsaro  MOD: 


cx:b  process  control 

APPROVAL: _ ^DATE: _ APPROVAL _ ^DATE:. 


PURPOSE:  Identify  a  standard  for  incorporating  Software  Problem/Change  Report  (SP/CR) 
audit  trails  when  source  code  is  added,  deleted  or  modiHed.  A  SP/CR  audit  trail  history  which 
documents  tte  description  and  reason  for  the  change  is  required  in  the  header  comment  blodr  for 
each  change  made  to  a  new  or  modified  file.  Lii^  of  code  are  not  required  to  be  documented  widi 
a  SP/CR  audit  trail  within  new  modules  only  in  the  header  comment  block.  SP/CR  audit  trails 
provide  traceability  of  each  change  made  to  a  module  during  the  software  development  and 
maintenance  phases  of  a  project 

The  following  is  a  list  of  SP/CR  audit  trail  standards: 

a.  The  prologue  header  comment  block  contains  the  audit  trail  history  data.  The  most  recent 
SP/CR  audit  trail  history  shall  be  documented  as  the  last  entry  in  the  header  comment 
block. 

b.  The  SP/CR  audit  trail  shall  be  entered  as  a  comment  at  the  end  of  the  modified  line  of  code. 
For  example: 

/•  SP/CR  100*  / 

c.  Multiple  SP/CR  audit  trails  affecting  the  same  line(s)  of  source  code  shall  be  concatenated. 
For  example: 

/*  SP/CR2,SP/CR36,SP/CR100  */ 

d.  New  modules  added  in  response  to  a  SP/CR  shaU  have  an  initial  audit  trail  entry  in  the 
header  comment  block  wUch  identifies  the  module  as  new  and  associates  it  with  the 
SP/CR.  Subsequent  lines  of  code  within  the  new  module  need  not  be  annotated  with  the 
SP/C^  audit  traiL 

e.  When  code  is  added  to  a  module,  insert  the  SP/CR  audit  trail  and  following  comments  in 
the  beginning  and  end  of  the  new  lines  of  code.  This  shall  be  in  addition  to  the  normal 
audit  t^  histoiy  in  the  header  comment  block  at  the  beginning  of  the  module. 

/•  SP/CR15S  START  OF  NEW  CODE  ADDED  */ 


1/19/93 


SSOP  #0014 


C-26 


ADST 

SOFTWARE  SUPPORT  OPERATING  PROCEDURE 

insert  new  code 

/•  SP/CRISS  END  OF  NEW  CODE  ADDED  */ 

f .  When  code  is  deleted,  a  SP/CR  audit  trail  and  following  comments  shall  be  documented  at 
the  point  of  code  deletion.  The  code  shall  not  be  physicaUy  deleted.  Each  line  of  deleted 
code  should  be  annotated  with  a  comment  symbol.  (Be  careful  that  the  comment  symbol  is 
not  embedded  in  what  you  are  deleting  because  this  will  cause  an  error  during  compilaticm). 
This  shall  be  in  addition  to  the  normd  audit  trail  history  provided  in  the  header  comment 
block  at  the  beginning  of  the  module. 

/*  SP/CRlSS  END  OF  CODE  DELETION*/ 

/*  add  comment  symbol  before  and  after*/ 

/*  each  line  of  deleted  code  */ 

/*  SP/CR155  END  OF  CODE  DELETION*/ 

g.  The  date  which  is  used  to  document  an  SP/CR  audit  trail  entry  in  the  header  conunent  block 
sludl  take  the  format  DD-MMM-YYYY.  For  example: 

30‘Nov-1992 
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APPENDIX  D.  GLOSSARY 


Acceptance  Testing  Formal  testing  conducted  to  determine  whether  or  not  a 

system  satisfies  its  acceptance  criteria. 


AMtroYal 

Baseline 


Formal  recognition  of  the  validity  and  acceptability  of  an 
action  or  a  product 

A  specifictuion  or  product  that  has  been  reviewed  and  agreed 
upon,  and  thereafter  serves  as  a  basis  for  further 
development  A  baseline  can  be  changed  only  through 
change  control  procedures.  (2)  A  configuration 
identification  document  or  set  of  documents  formally 
designated  by  the  Government  and  fixed  at  a  specific  time 
during  the  system's  life  cycle.  Baselines,  plus  approved 
changes  from  these  baselines,  constitute  the  current 
configuration. 

The  compilation  and  linking  of  source  code  into  the  program 
executable  images  that  run  on  the  target  simulator,  bicluded 
as  of  the  buUd  are  any  data  files  or  data  bases  required  to 
initialize  and/or  support  the  execution  of  the  programs  in  the 
simulators. 


Build  Load  The  program  executable  images  that  run  on  the  target 

simulator  and  any  data  files  or  data  bases  required  to 
initialize  or  support  the  operation  of  the  simulator. 

Configuration  Control  Board  Focal  point  for  all  changes  to  the  BDS-D  software  product 

baselines.  The  CCB  will  ensure  proper  application  of 
configuration  control  and  establish  the  basis  for  status 
accounting.  The  CCB  will  provide  active  program  support 
for  monitoring,  coordinating,  and  implementing  change 
control 


Configuration  Identification  The  process  controlling  the  approved  products  in  a  system 

and  recording  their  characteristics,  such  as  numbers  and 
other  identifiers  affixed  to  the  items  and  documents.  The 
approved  documents  that  identify  and  define  the  item's 
functional  and  physical  characteristics  in  the  f^orm  of 
specifications,  drawings,  associated  lists,  interface 
documents,  and  documents  referenced  therein. 

Configuration  Item  ^  aggregation  of  hardware,  firmware,  software,  or  any  of 

its  discrete  portions,  which  satisfies  an  end  use  function  and 
is  designated  for  configuration  management 

Configuration  Management  A  discipline  applying  technical  and  administrative  direction 

and  survdllance  to  (a)  identify  and  document  the  functional 
and  physical  characteristics  of  CIs,  (b)  control  changes  to 
Os  and  related  documentation,  (c)  record  and  report  change 
information  needed  to  manage  CIs  effectively,  including  the 
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APPENDIX  E.  ACRONYMS 


ADST 

BDS-D 

CCB 

CM 

CMP 

Cl 

CSCI 

DBMS 

DO 

ECP 

EDMS 

EDS 

FCA 

PCI 

GFE 

H/W 

lAW 

IDD 

IRS 

I&T 

PCA 

PEM 

POC 

PMO 

RCS 

SCM 

SDD 

SDF 

SDP 

SIMNET 

SMM 

SOW 

SPC 

SP/CR 

SPS 

SQA 

SRS 

SSL 

SSOP 

STD 

STP 

S/W 

sweep 

TRR 

VDD 

V&V 

WDL 


Advanced  Distributed  Simulatioo  &  Training 
Battlefield  Distributed  Simulation-Development 
Configuration  Gxitrol  Board 
Configuration  Management 
Configuratitm  Management  Han 
Configuration  Item 

Cennputer  Software  Configuration  Item 
Data  Base  Management  System 
Delivoy  Order 

Engineering  Change  Proposal 
Engineering  Data  Management  System 
ElectrcMiic  Defense  Systems 
Functional  Configuration  Audit 
Functional  Configuration  Item 
Government  Furnished  Equipment 
Hardware 
In  Accordance  With 
Interface  Desi^  Document 
Interface  Requirements  Specification 
Integration  and  Test 
Hiysical  Configuration  Audit 
Program  Engineering  Manager 
Point  of  Contact 
Ptoffam  Managemoit  Office 
Revision  Ccmtrol  System 
Software  Configuration  Management 
Software  Design  Document 
Software  Devdqnnent  File 
Software  Devdofanent  Plan 
Simulation  Networking 
Software  Maintenance  Manual 
Statement  of  Wo± 

Software  Process  Control 
Software  Problem/Change  Report 
Software  Product  Specification 
Software  Qualipr  Assurance 
Software  Requirements  Specification 
Software  Support  Library 
Software  Supix>rt  Operating  Procedures 
Software  Test  Description 
Software  Test  Plan 
Software 

Software  Support  Contraa  Change  Proposal 
Test  Readiness  Review 
Version  Description  Document 
Verification  and  Validadrai 
Western  Development  Labs 
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